What is the precision of the BigFloat you wrote above?
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! >>> >>> >>>
