Reliable segfault with >4d array

[timholy]

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

[timholy]

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]

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

[timholy]

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

[timholy]

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]

Stack trace or valgrind?

[ViralBShah]

Yup, segfaults for me too.

[ViralBShah]

Looks like the segfault happens in the call to DSFMT.

[ViralBShah]

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]

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]

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]

Works for me now.

[timholy]

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