--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.
So am I, so that isn't the difference.
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 ran test-qof under lldb and stopped at malloc_error_break. Using
this with various malloc-related environment variables gave me a stack
traces for where the offending block was allocated and one for where it
was released. I've put these in a file in
<https://www.dropbox.com/sh/wghtw6xnqv4ygc5/AACtTnDB1oKgSnFoD_E6zREAa?dl=0>
along with the crash reports. It looks like it's a character string
allocated by IANAParser, but I haven't looked further yet. It's quite
possible that this string is only an innocent victim of some code that
thinks it is changing something else.
Mike
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
