Hi Tim, Patrick, Thanks for your answers. I just realized that the mistake was totally mine. Basically I had changed the definition of the abstract type of the object in question. My apologies. I guess the possibility of storing the definition of the abstract type along with the object and/or more explicit error messages (it took me a while simply to understand that the segfault was caused by something related to HDF5) could be useful, although it is a pretty silly thing to do (changing the type and trying to load the object), so I am not looking for excuses!
At least now I know about debugging.md ;) Ben On Friday, March 7, 2014 4:49:56 PM UTC-5, Tim Holy wrote: > > First I've heard of this problem, and it's hard to debug without more > information. > > If the problem appeared in v0.2.18, you could just say "git checkout > v0.2.17" > and see if that causes the segfaults to go away. > > If you updated your Julia as well, of course the segfault could be there. > > There are instructions on capturing backtraces in various places, for > example > the FAQ and (the nicest): https://gist.github.com/staticfloat/6188418 > > --Tim > > On Friday, March 07, 2014 10:43:08 AM ben wrote: > > Hi everyone, > > > > A couple of days ago, a module I have been working on for some time > started > > throwing segmentation faults frequently and at random. After a lot of > > head-scratching, I found out that the HDF5 package was causing this. > > > > My module starts by loading (with HDF5) some data that I processed a > month > > or so ago and stored on my hard drive in native Julia format (with > HDF5). > > The files did not change but the package was updated. > > > > I am not saying that this is a bug in the HDF5 package: maybe the > package > > is not fully backward-compatible with old data, maybe I just need to > > re-process and re-store the data. I don't have the time to investigate > > right now so I am posting this hoping that it will save someone > redundant > > head-scratching :) > > > > Ben >
