unexpectedly broad tuple type in Optim.hz_linesearch!

[timholy]

Using the master branch of Optim, and modifying the default value of this line to 0x23 results in a reliable segfault when running test/runtests.jl.

julia> versioninfo()
Julia Version 0.3.0-prerelease+1942
Commit 4e1e0ab* (2014-03-10 06:23 UTC)
DEBUG build
Platform Info:
  System: Linux (x86_64-linux-gnu)
  CPU: Intel(R) Core(TM) i7 CPU       L 640  @ 2.13GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
  LAPACK: libopenblas
  LIBM: libopenlibm

tim@diva:~/.julia/v0.3/Optim/test$ gdb --args julia runtests.jl 
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/tim/src/julia/julia...done.
(gdb) r
Starting program: /home/tim/src/julia/julia runtests.jl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff1dd5700 (LWP 24918)]
[New Thread 0x7fffeef50700 (LWP 24919)]
[New Thread 0x7fffea74f700 (LWP 24920)]
Running tests:
 * bfgs.jl

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff755da20 in llvm::Value::getContext() const () from /home/tim/src/julia/usr/bin/../lib/libjulia-debug.so
(gdb) bt
#0  0x00007ffff755da20 in llvm::Value::getContext() const () from /home/tim/src/julia/usr/bin/../lib/libjulia-debug.so
#1  0x00007ffff752f4ed in llvm::StoreInst::StoreInst(llvm::Value*, llvm::Value*, bool, llvm::Instruction*) ()
   from /home/tim/src/julia/usr/bin/../lib/libjulia-debug.so
#2  0x00007ffff6c25864 in llvm::IRBuilder<true, llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true> >::CreateStore (
    this=0x7ffff7ae7a80, Val=0x0, Ptr=0x4a432c0, isVolatile=false) at /home/tim/src/julia/usr/include/llvm/IR/IRBuilder.h:866
#3  0x00007ffff6bf2407 in emit_tupleset (tuple=0x2140ab0, ival=0x1b42110, x=0x0, jt=0x1f410b0, ctx=0x7fffffff8a60) at cgutils.cpp:986
#4  0x00007ffff6bf4fdf in boxed (v=0x5cb84c8, ctx=0x7fffffff8a60, jt=0x1f410b0) at cgutils.cpp:1493
#5  0x00007ffff6c0fa6b in emit_assignment (l=0x5913bd0, r=0x52dbeb0, ctx=0x7fffffff8a60) at codegen.cpp:2190
#6  0x00007ffff6c1081a in emit_expr (expr=0x52dbe90, ctx=0x7fffffff8a60, isboxed=false, valuepos=false) at codegen.cpp:2379
#7  0x00007ffff6c16458 in emit_function (lam=0x644dba0, cstyle=false) at codegen.cpp:3516
#8  0x00007ffff6bf5a9a in to_function (li=0x644dba0, cstyle=false) at codegen.cpp:405
#9  0x00007ffff6bf5f32 in jl_compile (f=0x2db0860) at codegen.cpp:514
#10 0x00007ffff6be1061 in jl_get_specialization (f=0x3a37d70, types=0x439cb90) at gf.c:1301
#11 0x00007ffff6c0a95a in emit_known_call (ff=0x3a37d70, args=0x47bd630, nargs=18, ctx=0x7fffffffa8f0, theFptr=0x7fffffffa300, 
    theF=0x7fffffffa308, expr=0x60a11e0) at codegen.cpp:1332
#12 0x00007ffff6c0e630 in emit_call (args=0x47bd630, arglen=19, ctx=0x7fffffffa8f0, expr=0x60a11e0) at codegen.cpp:1910
#13 0x00007ffff6c107d8 in emit_expr (expr=0x60a11e0, ctx=0x7fffffffa8f0, isboxed=true, valuepos=true) at codegen.cpp:2375
#14 0x00007ffff6c161cf in emit_function (lam=0x644d8d0, cstyle=false) at codegen.cpp:3488
#15 0x00007ffff6bf5a9a in to_function (li=0x644d8d0, cstyle=false) at codegen.cpp:405
#16 0x00007ffff6bf5f32 in jl_compile (f=0x4a889a0) at codegen.cpp:514
#17 0x00007ffff6be91a4 in jl_trampoline (F=0x4a889a0, args=0x7fffffffbbb8, nargs=8) at builtins.c:767
#18 0x00007ffff6bdcdb5 in jl_apply (f=0x4a889a0, args=0x7fffffffbbb8, nargs=8) at julia.h:964
#19 0x00007ffff6be1295 in jl_apply_generic (F=0x3a37d70, args=0x7fffffffbbb8, nargs=8) at gf.c:1376
#20 0x00007ffff7e64834 in ?? ()
#21 0x00000000053d7df0 in ?? ()
#22 0x0000000000000002 in ?? ()
#23 0x00007fffffffbc00 in ?? ()
#24 0x0000000000a3f210 in ?? ()
#25 0x795b2a4cb04c5d00 in ?? ()
#26 0x3ff0000000000000 in ?? ()
#27 0x7ff0000000000000 in ?? ()
#28 0x0000000000698920 in ?? ()
#29 0x0000000000698920 in ?? ()
#30 0x0000000000000004 in ?? ()
#31 0x0000000003d8fa00 in ?? ()
#32 0x0000000004fa9d80 in ?? ()
#33 0x0000000004a77b40 in ?? ()
#34 0x0000000004a77b00 in ?? ()
#35 0x0000000004a763c0 in ?? ()
#36 0x0000000003d8eae0 in ?? ()
#37 0x0000000003a37d70 in ?? ()
#38 0x00007ffff6be921c in jl_trampoline (F=0x4cce610, args=0x795b2a4cb04c5d00, nargs=0) at builtins.c:775
#39 0x00007ffff7e63b54 in ?? ()
#40 0x0000000002015e20 in ?? ()
---Type <return> to continue, or q <return> to quit---
#41 0x0000000004cce610 in ?? ()
#42 0x00007fffffffbe70 in ?? ()
#43 0x0000000000000002 in ?? ()
#44 0x00007fffffffbe50 in ?? ()
#45 0x0000000003d8ea60 in ?? ()
#46 0x795b2a4cb04c5d00 in ?? ()
#47 0x00007fffffffbe70 in ?? ()
#48 0x00007fffffffcbe8 in ?? ()
#49 0x0000000001d36f30 in ?? ()
#50 0x00007fffffffbd00 in ?? ()
#51 0x00007ffff6be5d50 in jl_apply (f=0x7fffffffbe70, args=0x795b2a4cb04c5d00, nargs=0) at julia.h:964
Backtrace stopped: frame did not save the PC
(gdb) 

[timholy]

Note you can also comment out that final argument entirely, and simply set display = 0x23 in the body of the code and get the segfault. Finally, it has nothing to do with the variable being named display.

[timholy]

Unfortunately I was not able to replicate this with a simple test like

const one64 = convert(Uint64, 1)
const FINAL       = one64
const ITER        = one64 << 1
const PARAMETERS  = one64 << 2

function myfunc()
    detailed_trace = 0x23
    if detailed_trace & FINAL > 0
        println("Final")
    end
end

[JeffBezanson]

What I see so far is that the type of bisect! is correctly inferred to be (Int,Int,Int,Int), except in the context of hz_linesearch!, where it is recorded as (Int64,Union(Uint8,Int64),Int64,Int64). No idea where that type came from. Quite strange.

[JeffBezanson]

The crash is fixed. There is just some wonky sub-optimal type inference which might be a bug, not sure.

[timholy]

That is odd. Thanks for fixing the crash!

I'll let you be the one to decide when to close this.

[stevengj]

It's not clear to me that the crash is fixed, because now it is crashing PyCall... see my comment at 764098f.

[carlobaldassi]

@stevengj it works for me on master now.

[stevengj]

Yup, no crash for me any more.