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

mysterious assertion failure when reinterpreting subarrays #7897

Closed
staticfloat opened this issue Aug 7, 2014 · 5 comments
Closed

mysterious assertion failure when reinterpreting subarrays #7897

staticfloat opened this issue Aug 7, 2014 · 5 comments
Assignees
Labels
kind:bug Indicates an unexpected problem or unintended behavior

Comments

@staticfloat
Copy link
Sponsor Member

In my naive attempts to chase the performance rabbit, I came across this interesting case:

function breakme!(data)
    data = reinterpret(Uint32, data)
    a = data[1]
end

a = ones(Uint8, 10)
sa = sub(a,4:6)
breakme!(sa)

This causes the following assertion failure:

$ julia breakme.jl 
Assertion failed: (jb->instance != NULL), function static_void_instance, file ./cgutils.cpp, line 1436.

signal (6): Abort trap: 6
__pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)
Abort trap: 6

Surprisingly, if I comment out the a = data[1] line, I get something much more sane:

$ julia breakme.jl 
ERROR: auto_unbox: unable to determine argument type
 in breakme! at /Users/sabae/breakme.jl:2
 in include at /usr/local/Cellar/julia/HEAD/lib/julia/sys.dylib
 in include_from_node1 at loading.jl:128
 in process_options at /usr/local/Cellar/julia/HEAD/lib/julia/sys.dylib
 in _start at /usr/local/Cellar/julia/HEAD/lib/julia/sys.dylib (repeats 2 times)
while loading /Users/sabae/breakme.jl, in expression starting on line 8

And it's not the fact that it's trying to read in from data that's confusing it; it's the fact that there is an array read at all; it could be a completely different array, and Julia still throws a hissy fit:

function breakme!(data, arr)
    data = reinterpret(Uint32, data)
    a = arr[1]
end

a = ones(Uint8, 10)
sa = sub(a,4:6)
breakme!(sa, zeros(10))
@staticfloat staticfloat added the bug label Aug 7, 2014
@Keno Keno self-assigned this Aug 8, 2014
@Keno
Copy link
Member

Keno commented Aug 8, 2014

I fixed the assertion failure (not pushed yet though), but I'm wondering what reinterpret on a subarray should do. Opinions @JeffBezanson @StefanKarpinski?

@staticfloat
Copy link
Sponsor Member Author

I think it's reasonable to just plain disallow that for now (it would be really really nice if we could reinterpret subarrays or array views, or whatever you want to call that though). I opened this issue because of the strange failure though.

@Keno
Copy link
Member

Keno commented Aug 8, 2014

Alright, I'll fix the assertion failure and we can discuss subarray reinterpret later.

@Keno Keno closed this as completed in 6bd8b56 Aug 8, 2014
@sebastiang
Copy link

What is the status of SubArray reinterpretation? If regular array views (x[a:b]) start being treated this way, it will be a regular occurrence.

@timholy
Copy link
Sponsor Member

timholy commented Oct 22, 2014

It seems fairly likely that this will be doable, but I haven't really thought about it seriously yet.

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

4 participants