search

JuliaLang / julia

The Julia Programming Language
https://julialang.org/
MIT License
45.92k stars 5.49k forks source link

Reliable segfault with >4d array #993

Closed timholy closed 12 years ago

timholy commented 12 years ago

At commit 850109ebd1, changing to the "test" directory and running load("arrayperf.jl") causes a reliable segfault.

timholy commented 12 years ago

This is curious: the fault turns out to be in rand!:

julia> A = randn(4,4,4,4,4);

julia> A = zeros(4,4,4,4,4);

julia> A = rand(4,4,4,16);

julia> A = rand(4,4,4,4,4); Segmentation fault (core dumped)

What's really weird about it is that the last two lines have the same number of elements. To make matters even stranger: julia> A = zeros(4,4,4,4,4);

julia> A = reshape(A,4,4,4,16);

julia> size(A) (4,4,4,16)

julia> rand!(A); Segmentation fault (core dumped)

But this is not just dumb luck that it segfaulted this time, because I can call rand! repeatedly safely in 4 dimensions:

julia> for i = 1:1000 A = zeros(4,4,4,16) rand!(A) end

julia>

Very, very strange. I'm guessing there's a bug in the C-representation of the array?

JeffBezanson commented 12 years ago

I could not reproduce this on either 32- or 64-bit linux.

timholy commented 12 years ago

OK. I'm building from a fresh repository now, I'll let you know what happens.

timholy commented 12 years ago

Still happens on a fresh clone, running it from the usr/bin/.

$ gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

$ uname -a Linux diva 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Not sure what else would be helpful.

Anyone else see this? Easy to check: just do rand(4,4,4,4,4)

JeffBezanson commented 12 years ago

Stack trace or valgrind?

ViralBShah commented 12 years ago

Yup, segfaults for me too.

ViralBShah commented 12 years ago

Looks like the segfault happens in the call to DSFMT.

ViralBShah commented 12 years ago

Could the bug have to do with this?

Parameters:
dsfmt   dsfmt state vector.

array   an array where pseudorandom numbers are filled by this function. The pointer to the array must be "aligned" (namely, must be a multiple of 16) in the SIMD version, since it refers to the address of a 128-bit integer. In the standard C version, the pointer is arbitrary.

size    the number of 64-bit pseudorandom integers to be generated. size must be a multiple of 2, and greater than or equal to (SFMT_MEXP / 128) * 2.

Note:
memalign or posix_memalign is available to get aligned memory. Mac OSX doesn't have these functions, but malloc of OSX returns the pointer to the aligned memory block.
ViralBShah commented 12 years ago

Yup - this proves it:

julia> a = Array(Float64,4,4,4,4,4);

julia> mod(int(pointer(a)), 16)
8

julia> rand!(a)
Hangs...
JeffBezanson commented 12 years ago

OK, we should probably 16-byte align all arrays with element size >= 4. I don't know why I don't see the problem, but this explanation makes sense.

ViralBShah commented 12 years ago

Works for me now.

timholy commented 12 years ago

Ditto. Nice work, gentlemen, on a subtle issue!