I had the test code of a package I am developing for my PhD suddenly start crashing after a seemingly inoffensive commit.
The complete error log is here. It happens if I execute the tests in my last commit (i.e.,
git clone https://github.com/henriquebecker91/GuillotineModels.jl/
cd GuillotineModels.jl
git checkout 1f31094a
julia
julia> activate .
julia> instantiate
julia> test
)
The Julia version is 1.0.5 (the specific package versions are in the Manifest.toml file of the respository). The commit that introduced the error was this commit. In other words, if I checkout 9c2e654b instead (the previous commit) I do not have the crash. I had this problem with my Arch Linux laptop, and I used my mother’s Ubuntu laptop to reproduce it.
I do not have a MWE, but I have isolated the changes that make the problem appear, they are those changes (i.e., if I revert just those and keep the rest of the changes then the error disappear). They surprised me very much. I only changed the type of some parameters/return/literals of a single method from Int to the parametric type P that was already available in the scope, but most important, P is Int in the method call that gives the problem. (In fact, Int64, as Int is an alias for Int64 on my system that is a 64-bit architecture). The change, therefore, should make difference only if I used a different type for P in the future, but it crashes in a situation in which it should have made no difference (i.e., both Int and P refer to the same type Int64). If the error was not consistent I would question my RAM or SSD, as it seems bizarre.
For now I will just rollback my change, as it is not essential, it only avoided unnecessary integer conversions, but I would like to know what to do to avoid hitting this problem again.
1 Like
The first thing I would try is running on 1.4 and master. These bugs are frequently fixed in new releases.
Then, if the bug still persists, try to isolate an MWE. Also see similar open bugs.
1 Like
Thanks Tamas, 1.4 solves the problem, so I can be sure it will be fixed for a Long Term Version (LTS) like 2.0 in the future. However, I would like to know if this kind of bug is not fixed in LTS when found (in this case, the current LTS that is v1.0). I am now using the 1.0 version because it seems to be the best option developing a long/medium term reproducibility code for my PhD. There is the possibility that I will finish my PhD before Julia 2.0 goes out. Should I not worry about using a LTS version then? (I was using it because I thought it would receive this kind of bug fixing.) The best choice for a code that takes a long time to develop and needs to be available for a long time after it is not the LTS?
That should be a possibility, especially since there is no current timeline for 2.0 
If you can bisect the fix you can ask for it to be backported to 1.0.x, but frankly I do not think that sticking to 1.0.x is a good idea at this point unless you are willing to live with a lot of compromises (like this one). I would always use the latest major release as it comes with a lot of benefits.
1 Like
Bisected it:
41c0c2f42d8beb8d1e893a4bfb21d0cfae8b9b07 is the first new commit
commit 41c0c2f42d8beb8d1e893a4bfb21d0cfae8b9b07
Author: Jeff Bezanson <jeff.bezanson@gmail.com>
Date: Wed Jan 2 15:00:08 2019 -0500
don't use abstract_iteration for types with special cases in _apply (#30483)
(cherry picked from commit 3e6f60758fd9b974972a78bbe899bb754e97a533)
base/compiler/abstractinterpretation.jl | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
Tomorrow I will think about making a new issue or PR.
2 Likes