Is this a symptom of potential memory leak/corruption in Julia?

I had a Julia session open for 2 days. I wasn’t doing much, just testing little fragments of code. At the same time I had launched Jupyterlab with 2 Julia notebooks open and running. Julia has no contract that it is re-entrant, so I assume that each of the 3 running instances of Julia were completely separate.

Yet, here is what happened. I create a very simple sequence of commands that:

  1. create a 2 element array of Ints
  2. access each element and assign each to a different scalar variable

You’ll see that what happens in the corrupt example: the array gets mutated by the assignment and the second scalar assignment is wrong. Spooky!

Then, I end Julia and in the same shell instance (iterm2 on MacOS) restart Julia. Now, the simple sequence of statements work exactly as expected.

If Julia can get in a state like this, that is very disturbing. Or maybe something else is going on like the REPL getting out of sync, but it still seems odd.

It’s hard to reproduce stuff like this. I have the terminal log, but only 1000 lines of it.

julia> foo = [9,5]                   # start of sequence in "stale" Julia session
2-element Array{Int64,1}:
 9
 5

julia> nodelag = foo[1]            # this already looks wrong: should echo value of nodelag
2-element Array{Int64,1}:
 9
 5

julia> nodelag                         # but, this looks OK
9

julia> fromcond = foo[2]     # uh, oh: echoing incorrect value of foo, not the value of the scalar
9

julia> fromcond                # but this looks ok
5

julia> foo                         # UH, OH!   the value of foo has been mutated or re-allocated 
5

julia> typeof(nodelag)      # UH, OH!   nodelag should be a scalar Int64
2-element Array{Int64,1}:
 9
 5

julia> nodelag               # maybe the REPL is out of sync: this is value of the previous stmt.
Int64

julia> nodelag               # this seems OK
9

julia> nodelag              # just checking again--this is OK
9

julia> fromcond.          # UH, OH!   value of fromcond changed! or is the REPL out of sync?
9

julia>                            # I am somewhat freaked out.   Press ^d to terminate Julia
lewis@MacBook-Pro ~ % julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.5.0 (2020-08-01)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> foo = [9,5]                                    # create an assign foo in a new instance of Julia
 2-element Array{Int64,1}:
 9
 5

julia> nodelag = foo[1]                          # Ah
 9

julia> typeof(nodelag)                           # Ah
 Int64

julia> foo                                               # Everything looking good
 2-element Array{Int64,1}:
 9
 5

julia> fromcond = foo[2]                      # this echos the right result
 5

julia> typeof(fromcond)
 Int64

julia> foo                                            # nothing happened to Array foo
 2-element Array{Int64,1}:
 9
 5

julia> nodelag, fromcond = foo        # sort of funny thing to echo, but foo is not a tuple
 2-element Array{Int64,1}:
 9
 5

julia> nodelag                              # exactly as expected
 9

julia> fromcond                           # ditto
 5

julia> foo
 2-element Array{Int64,1}:          # ditto
 9
 5

julia>

This looks like an issue I’ve seen when using Revise where the output got delayed one step (https://github.com/timholy/Revise.jl/issues/195) but I haven’t seen that in a long time.

2 Likes

Yes, I am using Revise.

You are right, the pattern is a lag of one step in what Julia echos for result of a statement.

Probably internal values are correct (could have verified with some operation that accessed a variable but didn’t echo the var’s value). I won’t worry about it too much.

Something for Tim to look at over at Revise.jl?

1 Like

You should check your Revise version, see PSA: pin Revise at 2

1 Like