[release-0.18] Readd GLPK #1498
Conversation
|
The segfaults are back. One segfault on Julia v0.6 in |
|
Can't exactly say I'm surprised. However, at this point I'm finding it increasingly odd that we are constantly getting screwed on travis but can't reproduce this locally. I have still yet to ever encounter a single segfault locally. Can you reproduce in this PR? |
|
Would this help: https://docs.travis-ci.com/user/running-build-in-debug-mode/? |
|
Does this happen with the pre-binarybuilder version of GLPK? |
|
As I recall it was occurring on pre-binarybuilder versions of Clp, but I suppose you can check whether things are different with GLPK. |
|
So https://travis-ci.org/JuliaOpt/JuMP.jl/jobs/433523257#L309 points to a try/finally. There was a change in try/catch/finally in 0.7: https://github.com/JuliaLang/julia/blob/master/HISTORY.md:
There's no |
|
Hmm. The |
|
I think the statement @tkoolen is referring to refers to blocks which have only try
# stuff here
end |
|
Illegal instructions aren't supposed to happen in any case. This is a Julia bug no matter what. I think it's likely that the less-common |
|
@JeffBezanson, is there a chance that this case isn't being handled correctly after JuliaLang/julia#27559? I don't know Scheme at all, so any help would be very much appreciated; definitely not meant to point any fingers. For context, the illegal instructions @mlubin linked on Discourse are blocking a JuMP release that supports Julia 1.0. |
|
@tkoolen good spidey senses. I was able to reproduce the crash locally, and it's fixed by commenting out the |
|
JuMP's tests passed on 1.0 with GLPK (only) after the workaround in #1498 (comment) plus #1499 and JuliaOpt/GLPKMathProgInterface.jl#54. Haven't tried with other solvers yet. |
|
Awesome! This is with full tests, nothing commented out? |
Correct, I didn't comment anything out (besides the |
|
I reported the issue at JuliaLang/julia#29382. |
|
Without any solvers, tests pass on Julia v0.6. When adding GLPK, tests fails at this line: |
|
|
|
@mlubin @tkoolen Thanks for resolving the segfault on Julia v1.0, it was a nice surprise when waking up. |
Good idea, let's try that :) |
I don't think chasing down the line where the segfault happens will be too useful given the existing evidence. It's likely that something went wrong earlier and is revealed at an arbitrary later point. |
|
@blegat, have you tested with a non-binarybuilder solver? |
|
c34fab4 didn't seem to have any effect, it still crashes in operators.jl even though the solvers aren't loaded yet at that line !
Let's try https://github.com/JuliaOpt/JuMP.jl/tree/bl/csdp |
|
Another option for debugging: https://docs.travis-ci.com/user/running-build-in-debug-mode/#connecting-to-the-job-running-in-the-debug-mode |
|
It does not seem related to BinaryBuilder. CSDP does not use BB and loading it make tests fail: |
|
Debug mode is not enabled:
|
|
We have had significant changes in |
|
I believe the Travis people usually respond pretty quickly to debug mode requests if you shoot them an email. |
|
I'm able to reproduce the segfault locally with pretty high probability. It was too noisy for |
|
What is your technique to reproduce the bug since the travis status of this PR was green ? |
|
So if this is happening on line 367 of test/print.jl (on commit ee27487), it seems like GLPK may not be directly involved in this one. Can this be reduced to an example that doesn't involve GLPK at all? |
|
@tkoolen why do you say it is caused by ee27487 ? Have you bisected through the commits of #1432 ?
The segfault does not occur when there is no solver but it is thrown whatever is the solver loaded. Whether it is GLPK, CSDP or SCS. Even when moving the line |
Running |
No, ee27487 is just the last commit in that PR, so I was under the impression that the stack trace corresponds to that commit. Since that particular test case doesn't involve GLPK, I thought maybe there could be a chance that the crash is independent of GLPK, but perhaps that the presence of GLPK increases the chances of it happening. On the other hand, it's possible that memory corruption has already happened earlier. In any case, I think a good strategy would be to reduce the test code as much as possible (starting from ee27487) and see when the crash stops happening semi-reliably. Might also want to build Julia in debug mode with assertions enabled. |
Doesn't work on Arch Linux :/ I have pushed a branch https://github.com/JuliaOpt/JuMP.jl/tree/bl/PR1432 which is the same as the branch of #1432 to do the bisect on travis. |
|
@blegat Make sure to try the official linux binaries. It may depend on the version of LLVM given that the crash is inside LLVM. |
|
The Julia v0.6 segfault is resolved by 25a342d 🎉 |
blegat
force-pushed
the
bl/glpk
branch
2 times, most recently
from
20452dc to
1f61942
Compare
No description provided.