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

Segfault when adding new zeros method #16860

Closed
martinholters opened this issue Jun 10, 2016 · 4 comments
Closed

Segfault when adding new zeros method #16860

martinholters opened this issue Jun 10, 2016 · 4 comments
Labels
kind:bug Indicates an unexpected problem or unintended behavior

Comments

@martinholters
Copy link
Member

Discovered this in #16740.

The segfault happens on Travis' 64bit linux, no other CI, not my own 64bit linux, but I could nail it down using a branch in my repo, and it is actually sufficient to add a definition for zeros{T<:AbstractArray}(::Type{T}, dims...) (which is not even called).

The test triggering the segfault is arrayops.jl:177, and it occurs in sig_match_simple at typemap.c:127, see the travis output.

@ivarne ivarne added the kind:bug Indicates an unexpected problem or unintended behavior label Jun 10, 2016
@martinholters
Copy link
Member Author

Setting up a (virtual) machine with Ubuntu 12.04 and following the build steps from the travis configuration, I can now reproduce the problem. That allowed me to narrow it down to the following code resulting in a segfault:

import Base.zeros
zeros{T<:AbstractArray}(::Type{T}, dims...) = error("What, me? I'm not even being called!")

rng = (2,2:3,2:2:5)
tmp = zeros(Int,2,3,5)
tmp[rng...] = 1 # needs the splatting
B = cat(3,zeros(Int,2,3),zeros(Int,2,3),zeros(Int,2,3)) # needs three matrices cat'ed

I will try to bisect (assuming there is a version where this does not segfault) to figure out what might be going on...

@martinholters
Copy link
Member Author

Ah, good news: Segfault is gone in current master, specifically since e03f01c. However, considering how much the appearance of this bug depended on the build environment, I wonder whether the underlying cause has indeed been fixed or it is just better hidden now. CC @vtjnash
Should we close this, or do some more investigation?

@vtjnash
Copy link
Sponsor Member

vtjnash commented Jun 15, 2016

That commit seems a likely candidate for the fix. Since that commit was on master before this issue was found on travis, that may also suggest why it was hard to reproduce elsewhere?

@vtjnash vtjnash closed this as completed Jun 15, 2016
@martinholters
Copy link
Member Author

Since that commit was on master before this issue was found on travis, that may also suggest why it was hard to reproduce elsewhere?

No, the problem first occurred in #16740 before that commit (including the hard reproducibility) and I started my investigations from there. Anyway, I'm glad it's fixed! (And having it nailed down to that specific commit gives the confidence that it is fixed indeed.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Development

No branches or pull requests

3 participants