Invalid read on 32-bits introduced by tupocolypse

[garrison]

Since the merging of the tuple type redesign (#10380), valgrind (with -DMEMDEBUG) frequently reports invalid reads on 32-bits.

Here's a minimal test case: complex([1 2; 3 4], [5 6; 7 8]).

$ valgrind --smc-check=all-non-file ../julia -e "complex([1 2; 3 4], [5 6; 7 8])"
==24698== Memcheck, a memory error detector
==24698== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==24698== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==24698== Command: ../julia -e complex([1\ 2;\ 3\ 4],\ [5\ 6;\ 7\ 8])
==24698== 
==24698== Invalid read of size 4
==24698==    at 0x6098806: ???
==24698==    by 0x60986F4: ???
==24698==    by 0x40AAF13: jl_apply (julia.h:1276)
==24698==    by 0x40AED9E: jl_trampoline (builtins.c:1026)
==24698==    by 0x409FAC1: jl_apply (julia.h:1276)
==24698==    by 0x40A5433: jl_apply_generic (gf.c:1720)
==24698==    by 0x4135EC3: jl_apply (julia.h:1276)
==24698==    by 0x4136372: do_call (interpreter.c:63)
==24698==    by 0x4136F6A: eval (interpreter.c:210)
==24698==    by 0x413602C: jl_interpret_toplevel_expr (interpreter.c:25)
==24698==    by 0x415044D: jl_toplevel_eval_flex (toplevel.c:505)
==24698==    by 0x4150546: jl_toplevel_eval (toplevel.c:528)
==24698==  Address 0xfeb24580 is on thread 1's stack
==24698==  16 bytes below stack pointer

[garrison]

I'm not sure if this will provide any clue, but I get the invalid read the first two times this is called, but never on any calls after the second time.

$ valgrind -q --smc-check=all-non-file ./julia -q
julia> complex([1 2; 3 4], [5 6; 7 8])
==29011== Invalid read of size 4
==29011==    at 0x60A5B16: ???
==29011==    by 0x60A5A04: ???
==29011==    by 0x40AAF13: jl_apply (julia.h:1276)
==29011==    by 0x40AED9E: jl_trampoline (builtins.c:1026)
==29011==    by 0x409FAC1: jl_apply (julia.h:1276)
==29011==    by 0x40A5433: jl_apply_generic (gf.c:1720)
==29011==    by 0x4135DCF: jl_apply (julia.h:1276)
==29011==    by 0x413627E: do_call (interpreter.c:63)
==29011==    by 0x4136E76: eval (interpreter.c:210)
==29011==    by 0x4135F38: jl_interpret_toplevel_expr (interpreter.c:25)
==29011==    by 0x4150359: jl_toplevel_eval_flex (toplevel.c:505)
==29011==    by 0x4150452: jl_toplevel_eval (toplevel.c:528)
==29011==  Address 0xfec50660 is on thread 1's stack
==29011==  16 bytes below stack pointer
==29011== 
2x2 Array{Complex{Int32},2}:
 1+5im  2+6im
 3+7im  4+8im

julia> complex([1 2; 3 4], [5 6; 7 8])
==29011== Invalid read of size 4
==29011==    at 0x60A5B16: ???
==29011==    by 0x60A5A04: ???
==29011==    by 0x409FAC1: jl_apply (julia.h:1276)
==29011==    by 0x40A5333: jl_apply_generic (gf.c:1696)
==29011==    by 0x4135DCF: jl_apply (julia.h:1276)
==29011==    by 0x413627E: do_call (interpreter.c:63)
==29011==    by 0x4136E76: eval (interpreter.c:210)
==29011==    by 0x4135F38: jl_interpret_toplevel_expr (interpreter.c:25)
==29011==    by 0x4150359: jl_toplevel_eval_flex (toplevel.c:505)
==29011==    by 0x4150452: jl_toplevel_eval (toplevel.c:528)
==29011==    by 0x40AD146: jl_toplevel_eval_in (builtins.c:536)
==29011==    by 0x40AD32E: jl_f_top_eval (builtins.c:565)
==29011==  Address 0xfec50760 is on thread 1's stack
==29011==  16 bytes below stack pointer
==29011== 
2x2 Array{Complex{Int32},2}:
 1+5im  2+6im
 3+7im  4+8im

julia> complex([1 2; 3 4], [5 6; 7 8])
2x2 Array{Complex{Int32},2}:
 1+5im  2+6im
 3+7im  4+8im

julia> complex([1 2; 3 4], [5 6; 7 8])
2x2 Array{Complex{Int32},2}:
 1+5im  2+6im
 3+7im  4+8im

This seems to be a minimal test case, too -- 1D arrays don't do it, and passing an integer as one argument to complex and a matrix as the other argument doesn't cause the warning either.

[garrison]

Comparing two matrices also gives the invalid read. And again, the warning happens precisely twice if the comparison is called repeatedly.

julia> a = [1 2; 3 4]
2x2 Array{Int32,2}:
 1  2
 3  4

julia> a == a
==17142== Invalid read of size 4
==17142==    at 0x60AF156: ???
==17142==    by 0x60AF04E: ???
==17142==    by 0x60AEFD9: ???
==17142==    by 0x40AAF13: jl_apply (julia.h:1276)
==17142==    by 0x40AED9E: jl_trampoline (builtins.c:1026)
==17142==    by 0x409FAC1: jl_apply (julia.h:1276)
==17142==    by 0x40A5433: jl_apply_generic (gf.c:1720)
==17142==    by 0x4135DCF: jl_apply (julia.h:1276)
==17142==    by 0x413627E: do_call (interpreter.c:63)
==17142==    by 0x4136E76: eval (interpreter.c:210)
==17142==    by 0x4135F38: jl_interpret_toplevel_expr (interpreter.c:25)
==17142==    by 0x4150359: jl_toplevel_eval_flex (toplevel.c:505)
==17142==  Address 0xfeae46f0 is on thread 1's stack
==17142==  16 bytes below stack pointer
==17142== 
true

I am able to get this warning up to two times, and then if I run the complex minimal test case (given above) in the same REPL session, I can get up to two additional warnings from it.

[yuyichao]

Got a 32-bit container and got vgdb working.... here's the backtrace.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0801017b in julia_==_43936 (t1=<optimized out>, t2=<optimized out>)
    at tuple.jl:80
80      tuple.jl: No such file or directory.
(gdb) bt
#0  0x0801017b in julia_==_43936 (t1=<optimized out>, t2=<optimized out>)
    at tuple.jl:80
#1  0x08010075 in julia_complex_43935 (A=0xfeffd23c, B=0x2) at array.jl:871
#2  0x040ca018 in jl_apply (f=0x9f16ac0, args=0xfeffd23c, nargs=2)
    at julia.h:1280
#3  0x040cd9e5 in jl_trampoline (F=0x9f16ac0, args=0xfeffd23c, nargs=2)
    at builtins.c:961
#4  0x040bee5d in jl_apply (f=0x9f16ac0, args=0xfeffd23c, nargs=2)
    at julia.h:1280
#5  0x040c47eb in jl_apply_generic (F=0x9b441d0, args=0xfeffd23c, nargs=2)
    at gf.c:1767
#6  0x04162d66 in jl_apply (f=0x9b441d0, args=0xfeffd23c, nargs=2)
    at julia.h:1280
#7  0x041631de in do_call (f=0x9b441d0, args=0x9eea434, nargs=2, eval0=0x0, 
    locals=0x0, nl=0, ngensym=0) at interpreter.c:65
#8  0x04163d81 in eval (e=0x9ee7ec0, locals=0x0, nl=0, ngensym=0)
    at interpreter.c:212
#9  0x04162ebf in jl_interpret_toplevel_expr (e=0x9ee7ec0) at interpreter.c:27
#10 0x0417cf28 in jl_toplevel_eval_flex (e=0x9ee7e50, fast=1) at toplevel.c:507
#11 0x0417d010 in jl_toplevel_eval (v=0x9ee7e50) at toplevel.c:530
#12 0x040cc127 in jl_toplevel_eval_in (m=0x8884010, ex=0x9ee7e50)
    at builtins.c:538
#13 0x040cc2f5 in jl_f_top_eval (F=0x0, args=0xfeffd81c, nargs=2)
    at builtins.c:567
#14 0x05fa815e in julia_process_options_41937 (opts=0xfeffd988, args=0x2)
    at client.jl:288
#15 0x05fa7088 in julia__start_41936 () at client.jl:409
#16 0x05fa7a96 in jlcall.start_41936 ()
   from /build/julia-git/src/julia/usr/lib/julia/sys.so
#17 0x040ca018 in jl_apply (f=0x9b45ac0, args=0x0, nargs=0) at julia.h:1280
#18 0x040cd9e5 in jl_trampoline (F=0x9b45ac0, args=0x0, nargs=0)
    at builtins.c:961
#19 0x040bee5d in jl_apply (f=0x9b45ac0, args=0x0, nargs=0) at julia.h:1280
#20 0x040c4711 in jl_apply_generic (F=0x9b45a60, args=0x0, nargs=0) at gf.c:1743
#21 0x08048f42 in jl_apply (f=0x9b45a60, args=0x0, nargs=0)
    at ../src/julia.h:1280
#22 0x08049e2b in true_main (argc=0, argv=0xfeffdd10) at repl.c:441
#23 0x0804a02a in main (argc=0, argv=0xfeffdd10) at repl.c:494

[yuyichao]

@Keno This is what I get following your advice.

declare i1 @"julia_==_43936"([2 x i32], [2 x i32])

[yuyichao]

And the command on the gdb side

(gdb) p jl_function_ptr_by_llvm_name("julia_==_43936")
$2 = (void *) 0x28ea62a0
(gdb) p jl_dump_llvm_value(jl_function_ptr_by_llvm_name("julia_==_43936"))
$3 = void
(gdb) p jl_function_ptr_by_llvm_name("julia_complex_43935")
$4 = (void *) 0x28b19990
(gdb) p jl_dump_llvm_value(jl_function_ptr_by_llvm_name("julia_complex_43935"))
$5 = void

[yuyichao]

Also, jl_(jl_dump_function_asm(jl_function_ptr_by_llvm_name("julia_complex_43935"))) prints the assembly but p jl_(jl_dump_function_ir(jl_function_ptr_by_llvm_name("julia_complex_43935"), 0)) still only print the function name...

[Keno]

I assume that function is JITted? If so, you may have to enable KEEP_BODIES in options.h to see the assembly.

[yuyichao]

Actually running from gdb directly works (might has sth to do with where it is called).....

llvmir