> On May 7, 2015, at 12:27 AM, Mike Alexander <m...@umich.edu> wrote: > > --On May 5, 2015 at 6:18:09 PM -0700 John Ralls <jra...@ceridwen.us> wrote: > >> I obviously haven’t encountered that problem, and ISTM our >> environments for this purpose should be pretty much identical, at >> least when you’re using the Xcode compiler. The one possibility >> that comes to mind is optimization: I’m building with -O0 so that I >> can easily use the debugger. >> >> You can cd to src/libqof/qof and make check; you should get the same >> crash on test-gnc-timezone if you have google test or on test-qof if >> you don’t. That will provide a convenient program to run the >> debugger on to see if you can get some more info. >> >> The stack trace looks like the problem is coming from trying to reuse >> a supposedly freed block, so the real bug is probably somewhere else. >> Try setting $MallocScribble and see if it will crash where the real >> bug is. > > I just pushed a change that seems to fix this. The thing about my setup that > caused the failure is that (for reasons I haven't investigated) > sizeof(time_t) is 8 but I have a version 1 tzfile. The code that parsed the > timezone file was using sizeof(time_t) for the size of the offsets in the > file, but a version 1 file has 4 byte offsets no matter what sizeof(time_t) > is. This meant that it was byte swapping stuff that wasn't in the input > buffer (as well as putting junk in the transitions list, of course). > > I also pushed a trivial change to support version 3 tzfile format. Version 3 > is essentially identical to version 2 and the differences don't seem to > matter to this code. > > If you think my change is inappropriate let me know and I'll back it out.
Mike, Looks good. Surely you didn’t rebuild libc just to get a 64-bit time_t. What motivated you? Since you went to the work of replacing libc and the headers in your SDK (and have to redo it every time Apple pushes an Xcode upgrade), why not upgrade your TZ database as well? Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
