Segfault caused by deserialize (?) or too many tasks (?)

[eschnett]

For the past two weeks I've been trying to find the cause of a rather persistent segfault in a Julia program of mine. So far, I whittled it down to less then 1,000 lines of Julia code, and no external dependencies except Deque from DataStructures.jl (as a replacement for MPI.jl).

I create many tasks, many of them active (and yielding from time to time). I'm sure there's a lot of memory allocation and garbage collection going on. I also serialize and de-serialize many objects, including functions and lambdas.

The error is a segfault. I assume that there is a safe subset of Julia programs that should never segfault (no ccall, no @inbounds, etc.). I believe my program is safe in this respect.

Here is the code: https://bitbucket.org/eschnett/funhpc.jl/branch/memdebug. I apologize for the size -- I've already greatly reduced it. This is how to run it, and how it fails (after a few seconds):

$ ~/julia/bin/julia-debug Wave.jl
Wave[FunHPC.jl]
Initialization

signal (11): Segmentation fault: 11
unknown function (ip: 0)
Segmentation fault: 11

This with the current development version of Julia.

I believe the problem is somehow connected to or triggered by deserialization and/or by using many tasks. Deserialization is called from the file Comm.jl, routine recv_item, line 39. The result of the deserialize call is never used. If this call is commented out, the program runs fine (and output "Done."). (In my attempts to reduce code size, termination detection probably got wonky, but if the text "Done." is output, everything is fine, and the segfault avoided.)

Similarly, when I reduce the number of concurrent tasks (i.e. tasks that are runnable simultaneously, as opposed to waiting), the segfault becomes more sporadic, and disappears if there are just a few tasks. The current example runs 1000 tasks simultaneously.

When I attach a debugger, the segfault happens in array.c or gc.c in an allocation routine, with a seemingly impossible internal state. I assume that malloc's internal heap data structures have been destroyed by then. Adding assert statements didn't reveal anything. I can't use MEMDEBUG since this doesn't bootstrap since about five weeks ago ( #8422 ).

I tried SANITIZE=1, but this didn't bootstrap for me either.

I tried building Julia with both LLVM 3.3 and LLVM 3.5.

I tried running this via Travis instead on my laptop (OS X) and my workstation (Ubuntu) since I thought something may be wrong with my local setups, and Travis's setup should be well tested. However, I didn't have much luck there either -- debugging via Travis is too indirect to be productive.

I have looked in detail into the files array.c and gc.c (where the segfault is reported), as well as the file serialize.jl and iobuffer.jl (which handle deserialization), but I have not found any problems there. I would describe the programming styles of these files as "real world" rather than "Julia showcase", and the number of comments as "strictly for experts only" ( #8492 ), but they seem otherwise sound and well optimized.

I would be grateful for any comments or suggestions. At the moment, two promising courses of action seem either (1) make MEMDEBUG work again, or (2) investigate what happens during deserialization.

[eschnett]

@JeffBezanson Would you have time for a Skype call some time next week? I'm in the EST time zone. I want to continue to track this down. Either investigating bootstrapping with MEMDEBUG or looking at how functions are serialized seem promising next steps. For that I need to know more details about what your branch jb/size0stuff changed, or how functions (lambdas) are represented internally.

[JeffBezanson]

I can't do a call, but I found+fixed a bug that might be related (13638cd). I will keep working on this off and on if the segfaults persist.

[eschnett]

The segfault persists.

[JeffBezanson]

Another possible segfault fix: 819d9c8

[JeffBezanson]

I've fixed a couple more memory bugs. Worth checking again.

[eschnett]

Thanks. So far (i.e. a few days ago), things still reliably crash on two machines, and work flawlessly on a third. I don't understand this, as I'm using the same toolchain to build the same Julia version. I fear that LLVM code generation may be involved... Anyway, I'll test this again, after recovering from installing Yosemite.

[vtjnash]

deserialize(s, t::DataType) creates objects that aren't properly initialized until they are returned, which would probably segfault if the gc were to ever run while this function was on the stack:

julia/base/serialize.jl

Line 562 in e3a74ee

x = ccall(:jl_new_struct_uninit, Any, (Any,), t)

(edit: and i'm not really sure what it would do if it encountered an #undef, although it would perhaps just throw an undefined method deserialize(IO, UndefRefTag) error)

(edit2: between ser_tag -- which oddly isn't a WeakKeyDict --, deser_tag, and lambda_numbers the serializer assumes there is exactly one global serialize/deserialize pair (worldwide). however, since you aren't using multiple julia instances, I don't think this is your issue)

[JeffBezanson]

I think that function zeros the new object, so it should be ok. The _uninit
part is a bit of a misnomer.

[StefanKarpinski]

Ah, I had already written

Should jl_new_struct_uninit maybe zero memory so that GC can at least know not to follow junk pointers?

[vtjnash]

I think that function zeros the new object, so it should be ok. The _uninit
part is a bit of a misnomer.

ah, yes i see that now

[fundamental]

If any help is needed to verify this I'm getting the same/extremely similar segfault by just transmitting 1D floating point arrays and integers. It's a pretty deterministic segfault as well.

[JeffBezanson]

Is it possible to provide code that causes this? Ideally a fairly minimal test case? If you don't want to post it publicly you can email it to me directly.

[fundamental]

Right now it's in the middle of some unpublished research code, so I can't put it up directly, but I get the feeling that I should be able to reduce it to a minimal test case.
I'll update once the test is minimized and I verify that my system llvm isn't responsible.

[JeffBezanson]

Awesome, thanks!