Another crash

[Donald Allen]

I just managed to provoke a (the?) crash. I'm sorry, but I didn't get a
chance to rebuild gnucash with symbols (perhaps doing it after the fact
might help if you can't work with this? Or maybe not, since, as I recall, -g
turns off optimizations, so things might not be in the same place? It's been
awhile.). Anyway, here's the error and the stack trace:


Gtk-ERROR **: file gtktreemodelsort.c: line 2293
(gtk_tree_model_sort_clear_cache_helper): assertion failed: (level != NULL)
aborting...

Program received signal SIGABRT, Aborted.
0xffffe410 in __kernel_vsyscall ()
(gdb) backtrace
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb69c0aed in raise () from /lib/libc.so.6
#2  0xb69c2239 in abort () from /lib/libc.so.6
#3  0xb6b2f911 in g_logv () from /usr/lib/libglib-2.0.so.0
#4  0xb6b2f937 in g_log () from /usr/lib/libglib-2.0.so.0
#5  0xb6b2fc9a in g_assert_warning () from /usr/lib/libglib-2.0.so.0
#6  0xb720dde6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#7  0xb727990e in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#8  0xb732238d in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#9  0x000008f5 in ?? ()
#10 0xb7322d80 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#11 0xb73347d4 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#12 0x00000000 in ?? ()
(gdb)

I've got this thing sitting in gdb in an emacs buffer and will leave it
alone for awhile, so if there's anything else you want me to look at, get
back to me. If for some reason I need to destroy this, I'll generate a core
file with gdb. I do have some time today, so will rebuild gnucash with
symbols and try again.

/Don


On 2/14/07, Josh Sled <jsled at asynchronous.org> wrote:
>
> On Wed, 2007-02-14 at 07:35 -0500, Donald Allen wrote:
> > One other thing: is there a USE flag that I can set that would get
> > gnucash 2.0.1 built with symbols? Do you care, or will a stack trace
> > without symbols be good enough?
>
> It looks like the standard 'debug' use flag is supported;
> see /usr/portage/app-office/gnucash/gnucash-2.0.1.ebuild, in the
> src_compile function.
>
> I have a feeling that the intermittent symbols that would be present
> might be enough to at least localize the problem a bit, but more info is
> always better than less...
>
> --
> ...jsled
> http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo ${a}@${b}
>
>