Sorry, was making benchmarks and accidentally "fixed it". It turns out to
be an issue with deepcopying BigFloats. Here's a small test case:
immutable StackedArray{T,N,A} <: AbstractArray{T,N}
data::A
dims::NTuple{N,Int}
end
StackedArray(vec::AbstractVector) = StackedArray(vec, (length(vec),
size(vec[1])...)) # TODO: ensure all elements are the same size
StackedArray{A<:AbstractVector, N}(vec::A, dims::NTuple{N}) =
StackedArray{eltype(eltype(A)),N,A}(vec, dims)
Base.size(S::StackedArray) = S.dims
Base.getindex(S::StackedArray, i::Int) = S.data[ind2sub(size(S), i)...] #
expand a linear index out
Base.getindex(S::StackedArray, i::Int, I::Int...) = S.data[i][I...]
x = zeros(BigFloat,4)
storage = Vector{typeof(x)}(0)
for i = 1:100
x = -.5x + randn(size(x))
push!(storage,deepcopy(x))
end
S = StackedArray(storage)
# This print will cause a segfault
println(S)
That will segfault randomly if you get one of the bad bigfloats in there
(with the loop at 1000, that is pretty much every time).
On Tuesday, June 7, 2016 at 2:59:09 PM UTC-7, Jeffrey Sarnoff wrote:
>
> also -- this may or may not be relevant:
>
> from http://www.mpfr.org/mpfr-current/
>
>> *Warning! Due to the fact that Thread Local Storage (TLS) support is now
>> detected automatically, the MPFR build can be incorrect on some platforms*
>> (compiler
>> or system bug). Indeed, the TLS implementation of some
>> compilers/platforms is buggy
>> <http://www.loria.fr/~zimmerma/software/compilerbugs.html>, and MPFR cannot
>> detect every problem at configure time. Please run make check to see if
>> your build is affected. If you get failures, you should try the
>> --disable-thread-safe configure option to disable TLS and see if this
>> solves these failures. But you should not use an MPFR library with TLS
>> disabled
>> in a multithreaded program (unless you know what you are doing).
>>
>
> And it may be worth checking that you are not mixing Float64 values with
> BigFloat math (that can lead to Float64 overflow which looks as if it were
> a BigFloat problem).
>
> On Tuesday, June 7, 2016 at 5:49:09 PM UTC-4, Jeffrey Sarnoff wrote:
>>
>> e.g.
>>>
>> bigpi = BigFloat(pi);
>>
>> dump( bigpi )
>>
>> string( bigpi ) # if possible
>>
>>
>>
>>
>> On Tuesday, June 7, 2016 at 2:05:34 PM UTC-4, Pablo Zubieta wrote:
>>>
>>> It would help to have all the fields of the BigFloat, not only d (but
>>> also prec, sign and exp). I think it can be a problem with the printing
>>> functions, so having all that might help to figure where the problem is.
>>>
>>> On Tuesday, June 7, 2016 at 7:26:02 PM UTC+2, Chris Rackauckas wrote:
>>>>
>>>> That's the main issue here. I do have a way of creating them... in a
>>>> private branch that I cannot share right now (give it a month?). It's not
>>>> easy to create them either: essentially you can solve a really stiff SDE
>>>> and get them, so think about repeatedly taking random numbers in a loop,
>>>> multiplying them by small numbers, and accumulate them. Every once in
>>>> awhile these may pop up, but I don't have a minimal example right now that
>>>> does it. It's dependent on the chosen precision, so maybe my minimal
>>>> examples just weren't tough enough for it.
>>>>
>>>> However, I can dump the contents of the BigFloat:
>>>>
>>>> b = [unsafe_load(A[76].d,i) for i in 1:8]
>>>>
>>>> Any[0x255f4da0,0x00000000,0x6f702323,0x32363923,0x696c0030,0x6f635f61,
>>>> 0x335f7970,0x00343230]
>>>>
>>>> Other than that, it's hard to share since if it hits the REPL in any
>>>> way (printing, or default displaying) it segfaults. I only found them
>>>> because they show up as random zeros if you try to plot an array that has
>>>> them on Windows (on Linux Python just throws an error). If a Julia Dev
>>>> wants to take a look at it in more detail I'll give them temporary access
>>>> to the branch.
>>>>
>>>> Otherwise I'll keep this in the back of my mind and when I release
>>>> this part of the code I'll show exactly how bigfloats (and only bigfloats)
>>>> fail here, and cause a segfault. I wish I can be more open but my adviser
>>>> wants this code private until published, so I am sticking with it (again,
>>>> everything works except not sufficiently high precision bigs, so it's not
>>>> necessary for the paper at all).
>>>>
>>>> On Tuesday, June 7, 2016 at 9:58:23 AM UTC-7, Pablo Zubieta wrote:
>>>>>
>>>>> Do you happen to have a minimal reproducible example?
>>>>>
>>>>> On Tuesday, June 7, 2016 at 6:23:05 PM UTC+2, Scott Jones wrote:
>>>>>>
>>>>>> I've been trying to help @ChrisRackaukus (of DifferentialEquations.jl
>>>>>> fame!) out with a nasty bug he's been running into.
>>>>>> He is using `BigFloat`s, and keeps getting numbers that, when
>>>>>> printed, cause an MPFR assertion failure.
>>>>>> When I looked at these corrupted `BigFloat`s, I found the following
>>>>>> strings (they always started off corrupted at the location of the
>>>>>> pointer +
>>>>>> 8)
>>>>>>
>>>>>> *"##po#9620\0lia_copy_3024\0"*
>>>>>>
>>>>>> *"julia_annotations_3495\0\0"*
>>>>>>
>>>>>>
>>>>>> This corruption occurred both running on 64-bit Windows, and on Linux
>>>>>> (Centos), on Julia v0.4.5.
>>>>>>
>>>>>>
>>>>>> Thanks in advance for any clues as to what is causing this corruption!
>>>>>>
>>>>>>
>>>>>>
