On Tuesday, May 2, 2006 at 20:47:22 (-0700) Robert Ramey writes:
The inention is that archive classes be interchangeable. So if a serialization fails for one archive class and not for another, it would be a bug by definition.
Ok, that's good --- at least I'm not crazy. This will help in my efforts here on out.
As of now, there the only known instances of this occuring is with the serialization of Nan floating point numbers which fails on text/xml archives but passes with native binary archives.
I did confirm last night that the binary version is failing as well.
I do sympathize and much appreciate the effort you have to expend to narrow this down. It hasn't been reported so it must be pretty obscure. Sorry, I can't be of more help.
BTW, the best thing for me in these cases is to run under the debugger, trap when fault throws, and inspect the call stack (which is going to be long). So maybe it won't be so hard to track down once you can reproduce it.
Thanks for the note. I did run under the debugger --- the call stack was note merely long, it was unbelievable. I'm running on a reasonably fast, high-memory machine, and when I asked the debugger for a stack trace, it took over an hour to print 60,000+ frames. I gave up at that point. I also ran this under valgrind, but it fails and valgrind doesn't seem to notice the seg fault --- at least it doesn't print out anything useful (and I'm going whole hog with the options on valgrind to force it to be verbose). I'm going to give it another go today. If I can't make progress with this today, I'm going to have to abandon boost for the moment and move on with our current, hand-coded version of serialization. I think the boost approach is the way to go in the long term for us for many reasons, but I won't be able to spend too much more time on this. Hopefully something will pop up today that I can share with you. Thanks again. Bill