Loading User Modules in wrong order causes a freeze without errors

question

#1

Hello,

I have the following problem with my julia setup. I have about 10 user modules and they depend on each other and also on other mackages.

Now, when I load specific modules, e. g. with

using A
using B
using C

everything works. But changing the order, e. g.

using C
using A
using B

causes julia to freeze forever without any errors or warnings.

I place this question as a very general one because it would be a huge example when I would show you my real case or it would take a very long time to figure out a simple test case where it happens.

My questions are:

  1. how can I try to figure out what is going on here,
  2. does anyone has the same issue,
  3. is there a general rule on how modules are not allowed to depend on each other,
  4. is the order also important for performance?

Would be happy to discuss this issue with you. Thanks.


#2

No, it should generally be safe to load modules in whatever order you want. I would suggest trying to create a minimal example: pick a module, comment out half of the code, and see if the freeze still occurs. Then repeat until you can’t remove any more code without fixing the freeze, and post what’s left here.


#3

Are you sure it is freezed and not just taking a long time ? Have you waited up to 10 minutes ?
There is an issue with packages loading taking a very long time when they are loading in a certain order:


As a rule of thumb, the best way to avoid this issue is to to a topological sort and first load the package that are dependencies of other packages and then load the packages depending on them.


#4

No, I have just waited over 10 minutes and still no luck. I will try to find out, which part of the code causes the freeze.


#5

Hello, I found a code which, when excluded, removed the problem, however, I am not able to create a minimal example which reproduces the error without the rest of the files

The code is

Base.show(io::IO, T::Fit, args...; kwargs...) = println(io, string(T, args...; kwargs...))
Base.println(io::IO, T::Fit, args...; kwargs...) = println(io, string(T, args...; kwargs...))

#6

Are you using Julia v1.0.3 ? There have been a lot of fixes in that release.


#7

No, I am on 1.0.2 and I have quite a lot of issues with my code not running with 1.0.2. Before that I was using 1.0.0. Could you imagine it would help to upgrade?


#8

I have tested with 1.0.3 and the result is the same.


#9

Ah, that’s very useful information. The default implementation for string() internally uses show(), so your show() definition looks like it’s very likely to cause a stack overflow. Even worse, your show() calls println, which also calls string() which also probably calls show(), resulting in even more stack overflow goodness.

It’s possible that Julia is failing to compile that code, or that it’s simply stuck in a stack overflow trying to even print out your type.

Unless you’ve defined Base.string(::Fit) somewhere, then you should actually do the string conversion in Base.show. For example, I would suggest replacing both of those lines with:

Base.show(io::IO, T::Fit) = print(io, "This is a Fit")

#10

I have defined this in the module. The funny thing is that this module compiles just fine. But when using ThisModule is the followed with the next user module, than I do get the freeze. However, I still should look at how to define show and println probably.