-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Sporadic segfaults in v0.6.0-rc2 using ODBC package #22256
Comments
can you bisect to identify the specific commit that introduced the issue? |
Looks like #21620 (fixed by #22019 (comment)) |
which has no tests |
205bf77 is the first bad commit |
Thanks for the bisect @galenlynch. Ideally we could reduce the test case to something that didn't depend on ODBC, if possible. |
Yeah no problem! I have no idea what's causing the segfault inside ODBC because I don't understand the coredump or the error message that is produced when it occurs. The fact that it's stochastic, and seems to be influenced by the garbage collector, makes it harder to figure out. Given that the bad commit seems to be changing how Base does type inference on function returns, maybe looking at the |
I've determined that the segfault does not occur during execution of code in ODBC.jl, but instead during execution of code in DataStreams.jl (v0.1.3). After inserting a bunch of println statements, it seems like the segfault can happen as early as immediately before this line , and usually before anything in the I tried out some simple code to see if using a 'interface' package like DataStreams.jl to set the field of a subtype defined in another package caused the segfault, but that doesn't seem to reproduce the problem. |
Whether or not the bad commit segfaults seems to depend on what environment Julia runs in. If I try to query a database in Julia by itself, I get a segfault about 80% of the time. If I run Julia in gdb and try to run a query, it does not segfault and exits normally. If I run Julia in valgrind it does not segfault, but Julia stays alive long enough to produce a new error that it never reaches outside of valgrind:
Where using ODBC, DataStreams, DataFrames
db = ODBC.DSN("PostgreSQL")
src = ODBC.Source(db, "SELECT 1;")
Data.stream!(src, DataFrame, false, Dict{Int, Function}()) # this function call segfaults If I run the same valgrind command in the last good commit of Julia, I do not get this error. Here is the output of valgrind from commit 205bf77: valgrindout_firstbad.txt |
Aha! @vtjnash you were right, it is related to #21620. I made a 'minimal' example that shows memory corruption using an interface similar to DataStreams.jl, although I'm sure I could cook up a more minimal example that doesn't use an interface. First I make a __precompile__(true)
module FooInterface
export setbar_inner
abstract type FooType end # not exported, similar to DataStreams.jl
setbar_inner(a) = isdefined(a, :bar) ? (a.bar.inner = 1; nothing) : nothing # similar to DataStreams.jl
end Then I make a second module, __precompile__(true)
module Foo
using FooInterface
type Bar{AParameter}
inner::Int
end
type FooChild <: FooInterface.FooType
bar::Bar
end
function __init__()
a_foo = FooChild(Bar{true}(2))
setbar_inner(a_foo)
println("Attempted to set foo to 1, actually set it to ", a_foo.bar.inner)
end
end This results in stochastic memory corruption, presumably from the uninitialized memory warnings seen in the valgrind logs. for i in {1..8}
do
julia0.6 -e 'using Foo'
done
Attempted to set foo to 1, actually set it to 2
Attempted to set foo to 1, actually set it to 2
Attempted to set foo to 1, actually set it to 2
Attempted to set foo to 1, actually set it to 2
Attempted to set foo to 1, actually set it to 40532396646334466
Attempted to set foo to 1, actually set it to 40532396646334466
Attempted to set foo to 1, actually set it to 2
Attempted to set foo to 1, actually set it to 2 |
Thanks, that's was a great reduction! |
Will this fix the valgrind errors? Are they related to this bug, or are they separate? |
should fix those too |
I experience sporadic segfaults when using the ODBC.jl package, but only when I use julia v0.6.0-rc2 (not v0.5.2 or v0.6.0-rc1). At first I thought this was a problem with the ODBC package, but given the functions in the coredump (which seem to be related to memory allocation?) and the fact that I only experience the segfaults when using v0.6.0-rc2, I think this may be a julia bug and not a ODBC bug.
I don't know how to make a 'minimal example' of this bug, since it necessarily involves interacting with a database. However, the following causes a segfault about 80% of the time in julia v0.6.0-rc2:
Here is a coredump.txt produced by a different instance of the same bug.
The text was updated successfully, but these errors were encountered: