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.

Sign up for GitHub

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

Jump to bottom

LLVM ERROR when loading precompiled package #15533

Closed
yuyichao opened this issue Mar 16, 2016 · 3 comments · Fixed by #15556
Closed

LLVM ERROR when loading precompiled package #15533

yuyichao opened this issue Mar 16, 2016 · 3 comments · Fixed by #15556
Labels
bug Indicates an unexpected problem or unintended behavior regression Regression in behavior compared to a previous version

Comments

@yuyichao
Copy link
Contributor

Ref #15300 (comment)

I've just managed to reduce the test case to

__precompile__()

module PC

type PyObject
    function PyObject()
        po = new()
        finalizer(po, x->nothing)
        return po
    end
end

immutable PyGetSetDef
end

function jl_Function_call()
    PyObject()
    nothing
end

function __init__()
    PyObject()
    cfunction(jl_Function_call, Void, ())
    PyGetSetDef[PyGetSetDef()
                PyGetSetDef()]
end

end # module PC

It seems that the finalizer in PyObject, the cfunction call and the typed_vcat (instead of a getindex) are all very important for this to happen.

@vtjnash
@yuyichao yuyichao added bug Indicates an unexpected problem or unintended behavior regression Regression in behavior compared to a previous version labels Mar 16, 2016
@yuyichao
Copy link
Contributor Author

I reproduced this on both 0.5.0-dev+3106 and 0.5.0-dev+3177 (linux x64) repeatably with both the debug and release build.

@yuyichao
Copy link
Contributor Author

Part of the backtrace looks like

#88 cache_method (mt=mt@entry=0x7f6f2e7173a0, type=0x7f6f302e5180, type@entry=0x7f6f302e4eb0, method=<optimized out>, m=m@entry=0x7f6f2e77a010, 
    sparams=<optimized out>) at /home/yuyichao/projects/julia/master/src/gf.c:831
#89 0x00007f713320defe in jl_mt_assoc_by_type (mt=mt@entry=0x7f6f2e7173a0, tt=tt@entry=0x7f6f302e4eb0, cache=cache@entry=1, inexact=inexact@entry=1)
    at /home/yuyichao/projects/julia/master/src/gf.c:990
#90 0x00007f713320f718 in jl_method_lookup_by_type (cache=1, inexact=1, types=0x7f6f302e4eb0, mt=0x7f6f2e7173a0) at /home/yuyichao/projects/julia/master/src/gf.c:1392
#91 jl_get_specialization1 (types=0x7f6f302e4eb0, cyclectx=0x24273d0) at /home/yuyichao/projects/julia/master/src/gf.c:1445
#92 0x00007f71331c7628 in emit_call (args=args@entry=0x7f6f302e9450, arglen=5, ctx=ctx@entry=0x7ffce7f2eb90, expr=expr@entry=0x7f6f302fa890)
    at /home/yuyichao/projects/julia/master/src/codegen.cpp:2991
#93 0x00007f7133279641 in emit_expr (expr=0x7f6f302fa890, ctx=ctx@entry=0x7ffce7f2eb90) at /home/yuyichao/projects/julia/master/src/codegen.cpp:3465
#94 0x00007f713327e753 in emit_function (lam=lam@entry=0x7f6f30050d20, declarations=declarations@entry=0x7f6f30050da0, cyclectx=cyclectx@entry=0x24273d0, 
    definitions=0x7ffce7f2f0d0, definitions=0x7ffce7f2f0d0) at /home/yuyichao/projects/julia/master/src/codegen.cpp:4952
#95 0x00007f713327f701 in to_function (li=li@entry=0x7f6f30050d20, cyclectx=cyclectx@entry=0x0) at /home/yuyichao/projects/julia/master/src/codegen.cpp:851
#96 0x00007f713327fc85 in jl_compile_linfo (li=li@entry=0x7f6f30050d20, cyclectx=cyclectx@entry=0x0) at /home/yuyichao/projects/julia/master/src/codegen.cpp:1157
#97 0x00007f713320bc7a in jl_call_method_internal (nargs=1, args=0x7ffce7f2f2e8, meth=<optimized out>) at /home/yuyichao/projects/julia/master/src/julia_internal.h:65
#98 jl_apply_generic (args=args@entry=0x7ffce7f2f2e8, nargs=nargs@entry=1) at /home/yuyichao/projects/julia/master/src/gf.c:1863
#99 0x00007f713321eaa7 in jl_apply (nargs=1, args=0x7ffce7f2f2e8) at /home/yuyichao/projects/julia/master/src/julia.h:1262
#100 jl_module_run_initializer (m=0x7f6f2ef33190) at /home/yuyichao/projects/julia/master/src/module.c:625
#101 0x00007f713322d2c4 in jl_init_restored_modules (init_order=0x7f6f302825f0) at /home/yuyichao/projects/julia/master/src/dump.c:1820
#102 _jl_restore_incremental (f=f@entry=0x7ffce7f2f490) at /home/yuyichao/projects/julia/master/src/dump.c:2328
#103 0x00007f71332319c1 in _jl_restore_incremental (f=0x7ffce7f2f490) at /home/yuyichao/projects/julia/master/src/dump.c:2256
#104 jl_restore_incremental (fname=0x7f6f2f445e10 "/home/yuyichao/.julia/lib/v0.5/PC.ji") at /home/yuyichao/projects/julia/master/src/dump.c:2352

And at the top of the backtrace it hits llvm again in typeinf with,

#10 0x00007f7133274c95 in getAddressForOrCompileFunction (llvmf=<optimized out>) at /home/yuyichao/projects/julia/master/src/codegen.cpp:1063
#11 0x00007f713327569d in jl_generate_fptr (li=li@entry=0x7f6f302ecb10) at /home/yuyichao/projects/julia/master/src/codegen.cpp:1104
#12 0x00007f713320bc82 in jl_call_method_internal (nargs=3, args=0x7ffce7f1f260, meth=<optimized out>) at /home/yuyichao/projects/julia/master/src/julia_internal.h:66

Is this an issue with recursive codegen like #11956 ?

@vtjnash
Copy link
Sponsor Member

vtjnash commented Mar 17, 2016

That's my guess. I've started work on a branch to reduce this recursion dependency.

yuyichao added a commit to yuyichao/PyCall.jl that referenced this issue Mar 17, 2016
@yuyichao
Work around LLVM error. Ref JuliaLang/julia#15533
ce81258
@yuyichao yuyichao mentioned this issue Mar 17, 2016
Closed
vtjnash added a commit that referenced this issue Mar 18, 2016
@vtjnash
simplify interaction between new JITs and codegen
0b7171e 
this treats the new JITs (MCJIT, ORCJIT) much like the old JIT,
but using Module as the atomic unit instead of Function

this gets codegen closer to being separable (cachable) at the
module level, with the remerging happening in the JIT after object
file emission

TODO: memory optimization of strings in the JIT needs to be reimplemented

fix #15533
@vtjnash vtjnash mentioned this issue Mar 18, 2016
Merged
2 tasks
vtjnash added a commit that referenced this issue Mar 18, 2016
@vtjnash
simplify interaction between new JITs and codegen
32c093a 
this treats the new JITs (MCJIT, ORCJIT) much like the old JIT,
but using Module as the atomic unit instead of Function

this gets codegen closer to being separable (cachable) at the
module level, with the remerging happening in the JIT after object
file emission

TODO: memory optimization of strings in the JIT needs to be reimplemented

fix #15533
vtjnash added a commit that referenced this issue Mar 18, 2016
@vtjnash
simplify interaction between new JITs and codegen
2a65a90 
this treats the new JITs (MCJIT, ORCJIT) much like the old JIT,
but using Module as the atomic unit instead of Function

this gets codegen closer to being separable (cachable) at the
module level, with the remerging happening in the JIT after object
file emission

TODO: memory optimization of strings in the JIT needs to be reimplemented

fix #15533
vtjnash added a commit that referenced this issue Mar 21, 2016
@vtjnash
simplify interaction between new JITs and codegen
dcc3035 
this treats the new JITs (MCJIT, ORCJIT) much like the old JIT,
but using Module as the atomic unit instead of Function

this gets codegen closer to being separable (cachable) at the
module level, with the remerging happening in the JIT after object
file emission

fix #15533
vtjnash added a commit that referenced this issue Mar 22, 2016
@vtjnash
simplify interaction between new JITs and codegen
82af1e7 
this treats the new JITs (MCJIT, ORCJIT) much like the old JIT,
but using Module as the atomic unit instead of Function

this gets codegen closer to being separable (cachable) at the
module level, with the remerging happening in the JIT after object
file emission

fix #15533
vtjnash added a commit that referenced this issue Mar 22, 2016
@vtjnash
simplify interaction between new JITs and codegen
a727e16 
this treats the new JITs (MCJIT, ORCJIT) much like the old JIT,
but using Module as the atomic unit instead of Function

this gets codegen closer to being separable (cachable) at the
module level, with the remerging happening in the JIT after object
file emission

fix #15533
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Indicates an unexpected problem or unintended behavior regression Regression in behavior compared to a previous version
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

simplify interaction between new JITs and codegen JuliaLang/julia
2 participants
@vtjnash @yuyichao