Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

debug test assertion failure #1414

Closed
nolta opened this issue Oct 20, 2012 · 3 comments
Closed

debug test assertion failure #1414

nolta opened this issue Oct 20, 2012 · 3 comments

Comments

@nolta
Copy link
Member

nolta commented Oct 20, 2012

If i run:

$ cd test
$ gdb ../usr/bin/julia-debug-basic 
(gdb) r runtests.jl all

it crashes at intrinsics.cpp:164:

[Thread debugging using libthread_db enabled]
[New Thread 0x7fffef599700 (LWP 27349)]
[New Thread 0x7fffec76f700 (LWP 27350)]
[New Thread 0x7fffe7f6e700 (LWP 27351)]
[New Thread 0x7ffff0f4e700 (LWP 27352)]
     * all
     * core
     * numbers
     * strings
     * unicode
     * corelib
     * hashing
     * remote
     * arrayops
     * linalg
julia-debug-basic: intrinsics.cpp:164: llvm::Value* emit_unbox(llvm::Type*, llvm::Type*, llvm::Value*): Assertion `x->getType() == to' failed.

Program received signal SIGABRT, Aborted.
0x00000035a50330c5 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.13-2.x86_64 libgcc-4.5.1-4.fc14.x86_64 libgfortran-4.5.1-4.fc14.x86_64 libstdc++-4.5.1-4.fc14.x86_64
(gdb) bt
#0  0x00000035a50330c5 in raise () from /lib64/libc.so.6
#1  0x00000035a5034a76 in abort () from /lib64/libc.so.6
#2  0x00000035a502b905 in __assert_fail () from /lib64/libc.so.6
#3  0x00007ffff7381ef8 in emit_unbox (to=0x605c08, pto=0x6b6c00, x=0x3bf7de8) at intrinsics.cpp:164
#4  0x00007ffff739211c in emit_assignment (l=0x7616640, r=0xe96720, ctx=0x7fffffff67f0) at codegen.cpp:1343
#5  0x00007ffff7392bf3 in emit_expr (expr=0x1db63e0, ctx=0x7fffffff67f0, isboxed=false, valuepos=false) at codegen.cpp:1471
#6  0x00007ffff73966a6 in emit_function (lam=0x9f8bac0, f=0x5275520) at codegen.cpp:2034
#7  0x00007ffff737c115 in to_function (li=0x9f8bac0) at codegen.cpp:171
#8  0x00007ffff737c571 in jl_compile (f=0x5884690) at codegen.cpp:231
#9  0x00007ffff7372ff2 in jl_get_specialization (f=0xdab560, types=0x5884670) at gf.c:1264
#10 0x00007ffff738e282 in emit_known_call (ff=0xdab560, args=0x6f02cb0, nargs=2, ctx=0x7fffffff9120, theFptr=0x7fffffff80f8, 
    theF=0x7fffffff80f0, expr=0x2e9d930) at codegen.cpp:770
#11 0x00007ffff7390d2f in emit_call (args=0x6f02cb0, arglen=3, ctx=0x7fffffff9120, expr=0x2e9d930) at codegen.cpp:1154
#12 0x00007ffff7392bb1 in emit_expr (expr=0x2e9d930, ctx=0x7fffffff9120, isboxed=true, valuepos=true) at codegen.cpp:1467
#13 0x00007ffff738f2a9 in emit_known_call (ff=0xbb0cb0, args=0x6f02c60, nargs=2, ctx=0x7fffffff9120, theFptr=0x7fffffff8bb8, 
    theF=0x7fffffff8bb0, expr=0x2e9d910) at codegen.cpp:894
#14 0x00007ffff7390d2f in emit_call (args=0x6f02c60, arglen=3, ctx=0x7fffffff9120, expr=0x2e9d910) at codegen.cpp:1154
#15 0x00007ffff7392bb1 in emit_expr (expr=0x2e9d910, ctx=0x7fffffff9120, isboxed=true, valuepos=true) at codegen.cpp:1467
#16 0x00007ffff739654e in emit_function (lam=0x9e37860, f=0x5f437e0) at codegen.cpp:2018
#17 0x00007ffff737c115 in to_function (li=0x9e37860) at codegen.cpp:171
#18 0x00007ffff737c571 in jl_compile (f=0x5eebc40) at codegen.cpp:231
#19 0x00007ffff7379920 in jl_trampoline (F=0x5eebc40, args=0x7fffffffa6e8, nargs=2) at builtins.c:700
#20 0x00007ffff736f651 in jl_apply (f=0x5eebc40, args=0x7fffffffa6e8, nargs=2) at julia.h:903
#21 0x00007ffff73731f0 in jl_apply_generic (F=0xd1c360, args=0x7fffffffa6e8, nargs=2) at gf.c:1339
#22 0x00007ffff0edd9d8 in ?? ()
#23 0x0000000000000000 in ?? ()
@JeffBezanson
Copy link
Sponsor Member

Good catch, fix on the way. This is related to lapack.jl:391, which uses eps(Float32) regardless of the element type, which doesn't seem right. I believe we can pass -1 and have it pick for us. Don't know if this matters though.

@andreasnoack
Copy link
Member

Could this be related to #1398?

Also, can you elaborate on this issue even though it has been fixed? I am the author of lapack.jl:391 and agree that it is not very clever, but I cannot see why it should cause an error. As I understand it ccall should convert to the specified type. I am writing an update of that function and want to be as right as possible. In the new version the variable will be a FloatingPoint argument to the function.

@JeffBezanson
Copy link
Sponsor Member

It isn't an error, that was a compiler bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants