REPL-readline segfault

[timholy]

I believe this was the issue underlying the discussion re mysterious segfaults in JuliaGraphics/Gtk.jl#16

Copy/paste the following into the REPL:

n = 5
sleep(0.1)
@show n

For me this gives the result

julia> n = 5
5

julia> sleep(0.1)
readline: readline_callback_read_char() called with no handler!
Aborted (core dumped)

It does not cause the segfault if you put those commands in a .jl file and include it.

I was able to capture a backtrace using the procedure in the FAQ, with the exception that I used julia-debug-readline (as this doesn't happen with julia-debug-basic):

Program received signal SIGABRT, Aborted.
0x00007ffff6681425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff6681425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff6684b8b in __GI_abort () at abort.c:91
#2  0x000000000041a13f in rl_callback_read_char () at callback.c:116
#3  0x00000000004076df in jl_read_buffer (base=0x18d69b0 "@", nread=0) at repl-readline.c:859
#4  0x00007ffff7e127e5 in ?? ()
#5  0x0000000000000004 in ?? ()
#6  0x00007fffffffdc00 in ?? ()
#7  0x00000000006a1288 in ?? ()
#8  0x00000000018d6980 in ?? ()
#9  0x3efe8f5f6eaac500 in ?? ()
#10 0x00000000016e5ef0 in ?? ()
#11 0x0000000000403af0 in __mbrlen@plt ()
#12 0x00007fffffffde80 in ?? ()
#13 0x0000000000000000 in ?? ()

The key thing seems to be a sleep followed by an @; the following triggers the segfault

sleep(0.1)
@fred n

but

tic(); toc()
@fred

does not.

[gitfoxi]

Not necessarily just sleep, but maybe anything that takes a while. Try pasting this one:

using Tk
@show Tk

julia> using Tk
readline: readline_callback_read_char() called with no handler!
[1]    79093 illegal hardware instruction  julia-debug-readline

julia> n = 5
5

julia> sleep(0.1)
readline: readline_callback_read_char() called with no handler!
[1]    79093 illegal hardware instruction  julia-debug-readline

My illegal hardware instruction is a bit different from your Aborted (core dumped).

Running under lldb has a different effect. It locks up. If you Ctrl-C and take a backtrace it looks like:

Process 78557 stopped
* thread #1: tid = 0x1c6e0d, 0x00007fff8faba64a libsystem_kernel.dylib`kevent + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP
    frame #0: 0x00007fff8faba64a libsystem_kernel.dylib`kevent + 10
libsystem_kernel.dylib`kevent + 10:
-> 0x7fff8faba64a:  jae    0x7fff8faba654            ; kevent + 20
   0x7fff8faba64c:  movq   %rax, %rdi
   0x7fff8faba64f:  jmpq   0x7fff8fab6175            ; cerror_nocancel
   0x7fff8faba654:  ret
(lldb) bt
* thread #1: tid = 0x1c6e0d, 0x00007fff8faba64a libsystem_kernel.dylib`kevent + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP
    frame #0: 0x00007fff8faba64a libsystem_kernel.dylib`kevent + 10
    frame #1: 0x000000010014fddb libjulia-debug.dylib`uv__io_poll(loop=0x0000000100c72380, timeout=<unavailable>) + 667 at kqueue.c:130
    frame #2: 0x000000010014285d libjulia-debug.dylib`uv_run(loop=0x0000000100c72380, mode=UV_RUN_ONCE) + 317 at core.c:317
    frame #3: 0x0000000100119561 libjulia-debug.dylib`jl_run_once(loop=0x0000000100c72380) + 65 at jl_uv.c:231
    frame #4: 0x0000000103dbde00 sys.dylib`julia_process_events1534 + 144
    frame #5: 0x0000000103dbd738 sys.dylib`julia_event_loop1530 + 1208
    frame #6: 0x0000000103dbd8cd sys.dylib`julia_event_loop15309672 + 13
    frame #7: 0x000000010006df5c libjulia-debug.dylib`jl_apply(f=0x0000000101adc9c0, args=0x00007fff5fbff6b0, nargs=1) + 76 at julia.h:1046
    frame #8: 0x00000001000700bc libjulia-debug.dylib`jl_trampoline(F=0x0000000101adc9c0, args=0x00007fff5fbff6b0, nargs=1) + 636 at builtins.c:725
    frame #9: 0x000000010006240c libjulia-debug.dylib`jl_apply(f=0x0000000101adc9c0, args=0x00007fff5fbff6b0, nargs=1) + 76 at julia.h:1046
    frame #10: 0x0000000100064378 libjulia-debug.dylib`jl_apply_generic(F=0x0000000101adc980, args=0x00007fff5fbff6b0, nargs=1) + 520 at gf.c:1365
    frame #11: 0x0000000103a00fa8
    frame #12: 0x000000010006df5c libjulia-debug.dylib`jl_apply(f=0x0000000101889200, args=0x0000000000000000, nargs=0) + 76 at julia.h:1046
    frame #13: 0x00000001000700bc libjulia-debug.dylib`jl_trampoline(F=0x0000000101889200, args=0x0000000000000000, nargs=0) + 636 at builtins.c:725
    frame #14: 0x000000010010b23c libjulia-debug.dylib`jl_apply(f=0x0000000101889200, args=0x0000000000000000, nargs=0) + 76 at julia.h:1046
    frame #15: 0x000000010010b352 libjulia-debug.dylib`start_task(t=0x0000000102012a40) + 226 at task.c:410
    frame #16: 0x00000001001094e9 libjulia-debug.dylib`switch_stack(t=0x0000000102012a40, where=0x0000000102012a90) + 137 at task.c:199
    frame #17: 0x000000010010943b libjulia-debug.dylib`jl_switch_stack(t=0x0000000102012a40, where=0x0000000102012a90) + 43 at task.c:209
    frame #18: 0x0000000100108fed libjulia-debug.dylib`julia_trampoline(argc=0, argv=0x00007fff5fbff960, pmain=0x00000001000019b0, build_path=0x0000000000000000) + 189 at init.c:854
    frame #19: 0x0000000100001fe6 julia-debug-readline`main(argc=0, argv=0x00007fff5fbff960) + 198 at repl.c:289
    frame #20: 0x0000000100001094 julia-debug-readline`start + 52

Maybe libuv and libreadline don't get along?

I recall having to go through some heroics to get Julia to build (or not build) libreadline on various systems. There's a system version which may link against libncurses or libtinfo. On OSX it looks like it built libreadline ok, but it's always behaved a little screwy. Now I'm just typing to pass the time while it rebuilds with USE_SYSTEM_READLINE=1. The problem is still there. Ok, so either way then.

Maybe related: Sometimes (can't reproduce but wait around and it will happen to you) I will ^Z from Julia and try to do something like git push and then this:

Username for 'https://github.com': gitfoxi^M^M^M^M

That's me smashing the enter key until I remember, oh, this thing again and go do it in a new terminal.

[timholy]

Thanks, Jeff.