Possible Segfault With SIGINT And File IO

[fundamental]

When using ^C to abort code execution there appears to be a possible race condition which can lead to use after free cases which may result in a crash.

To replicate:

Make a test-case.jl file:

while(true)
    print('.')
end

open up the julia REPL and reload("test-case.jl").
While it's printing out dots, use ^C to abort.

50% of the time it seems to exit normally, but after subsequent reloads and aborts, you can get a reliable segfault

Valgrind shows where this issues seems to come from:

==844== Invalid read of size 8
==844==    at 0x4FA8B10: uv__stream_io (stream.c:890)
==844==    by 0x4FA171A: uv_run (core.c:643)
==844==    by 0x79C20F5: julia_process_events_41102 (stream.jl:550)
==844==    by 0x79C1FEB: julia_wait_41100 (task.jl:308)
==844==    by 0x79E5DCD: julia_wait_42130 (task.jl:223)
==844==    by 0x79F8D8B: julia_wait_full_42701 (multi.jl:570)
==844==    by 0x79F8C24: julia_take_21__42700 (multi.jl:741)
==844==    by 0x4F0D7CA: jl_apply_generic (julia.h:1281)
==844==    by 0x40780CF: ???
==844==    by 0x4078049: ???
==844==    by 0x4F0D7CA: jl_apply_generic (julia.h:1281)
==844==    by 0x4F159F7: jl_f_apply (julia.h:1281)
==844==  Address 0xa9cdf30 is 64 bytes inside a block of size 160 free'd
==844==    at 0x4C2966C: free (vg_replace_malloc.c:468)
==844==    by 0x79C166D: julia_uv_write_41076 (stream.jl:760)
==844==    by 0x79C1345: julia_buffer_or_write_41075 (stream.jl:771)
==844==    by 0x79C122E: julia_write_41074 (stream.jl:811)
==844==    by 0x79F36CA: julia_print_42568 (in /home/mark/julia/usr/lib/julia/sys.so)
==844==    by 0x79F36F1: jlcall_print_42568 (in /home/mark/julia/usr/lib/julia/sys.so)
==844==    by 0x4F0D7CA: jl_apply_generic (julia.h:1281)
==844==    by 0x4081DD5: ???
==844==    by 0x4F7141A: jl_toplevel_eval_flex.part.4 (julia.h:1281)
==844==    by 0x4F71EA0: jl_parse_eval_all (toplevel.c:549)
==844==    by 0x4F7209F: jl_load (toplevel.c:592)
==844==    by 0x77BB40F: julia_include_23430 (in /home/mark/julia/usr/lib/julia/sys.so)

All line numbers should correspond to commit 54e9ed1

[carnaval]

@vtjnash Now that the alignment stuff is on the way maybe you can have a look at the signal handler hack you were talking about :-)

[JeffBezanson]

I'm not sure that's the problem here. uv_write calls free in a finally block, so ^C can cause us to free it while the write is still pending. It's probably better to move the free to after stream_wait, so it only happens if the write is definitely done. Then the worst case is that we leak a couple bytes on ^C.

[vtjnash]

edit: #9450 (diff)

[vtjnash]

OP's issue fixed by 43e283d, although #14032, #2622, and #14190 (comment) are still needed to make this reliable