cygwin build produces SIGSEGV at startup #16921
Labels
system:windows
Affects only Windows
Milestone
Comments
|
Same error for today's Windows nightly binaries. |
|
probably #16907 |
|
confirmed by bisect to be e24fec2, cc @JeffBezanson Don't know why AppVeyor didn't have an issue. |
|
backtrace (it's failing an assertion when you run with julia-debug): |
|
I have 2 candidate patches to try. First patch: --- a/src/codegen.cpp
+++ b/src/codegen.cpp
@@ -3967,6 +3967,11 @@ static std::unique_ptr<Module> emit_function(jl_lambda_info_t *lam, jl_llvm_func
// step 1. unpack AST and allocate codegen context for this function
jl_array_t *code = (jl_array_t*)lam->code;
JL_GC_PUSH1(&code);
+ if ((jl_value_t*)code == jl_nothing) {
+ jl_type_infer(lam, 0);
+ code = (jl_array_t*)lam->code;
+ assert((jl_value_t*)code != jl_nothing);
+ }
if (!jl_typeis(code,jl_array_any_type))
code = jl_uncompress_ast(lam, code);
//jl_static_show(JL_STDOUT, (jl_value_t*)ast);Second patch: --- a/src/codegen.cpp
+++ b/src/codegen.cpp
@@ -874,16 +874,6 @@ static void to_function(jl_lambda_info_t *li)
// mark the pointer calling convention
li->jlcall_api = (f->getFunctionType() == jl_func_sig ? 0 : 1);
- // if not inlineable, code won't be needed again
- if (JL_DELETE_NON_INLINEABLE &&
- li->def && li->inferred && !li->inlineable && !jl_options.outputji) {
- li->code = jl_nothing;
- li->slottypes = jl_nothing;
- li->ssavaluetypes = jl_box_long(jl_array_len(li->ssavaluetypes)); jl_gc_wb(li, li->ssavaluetypes);
- li->slotflags = NULL;
- li->slotnames = NULL;
- }
-
// done compiling: restore global state
if (old != NULL) {
builder.SetInsertPoint(old);
@@ -1018,6 +1008,15 @@ extern "C" void jl_generate_fptr(jl_lambda_info_t *li)
if (li->fptr == NULL) {
li->fptr = (jl_fptr_t)getAddressForFunction((Function*)li->functionObjectsDecls.functionObject);
assert(li->fptr != NULL);
+ // if not inlineable, code won't be needed again
+ if (JL_DELETE_NON_INLINEABLE &&
+ li->def && li->inferred && !li->inlineable && !jl_options.outputji) {
+ li->code = jl_nothing;
+ li->slottypes = jl_nothing;
+ li->ssavaluetypes = jl_box_long(jl_array_len(li->ssavaluetypes)); jl_gc_wb(li, li->ssavaluetypes);
+ li->slotflags = NULL;
+ li->slotnames = NULL;
+ }
}
JL_UNLOCK(&codegen_lock); // Might GC
}Could somebody try these? @vtjnash I don't fully understand what's going on here. I can see why the second patch might be necessary, but it seems to significantly negate the memory savings. That says to me that I'm deleting IR that we need, but in that case why isn't the failure more widespread? |
|
The first patch is making the linker take an inordinate amount of time creating edit: first patch fails the added assertion |
|
I haven't previously mentioned it, but it is my impression that ld.exe has been taking a lot longer for a while, even before this patch. |
|
Possibly the change to linking llvm as a dll is to blame there, looks like it has nothing to do with the patch. |
|
I get an access violation with the second patch: |
|
The first patch gives me an access violation: |
|
I resolved the mystery of why appveyor didn't identify this - since it's building with |
|
Thanks, this gives me some good stuff to work with. |
|
Branch to try: #16936 |
|
Looks like that'll work. |
|
#16936 appears to work |
JeffBezanson
added a commit
that referenced
this issue
Jun 15, 2016
vtjnash
pushed a commit
that referenced
this issue
Jun 15, 2016
tkelman
added a commit
that referenced
this issue
Jun 16, 2016
this would have at least caught #16921 in local testing on platforms other than Windows
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
running master branch at dab5c8d
My last successful build was 0.5.0-dev+4707 at 2119ea6
The text was updated successfully, but these errors were encountered: