Another crash

[Donald Allen]

After my unsuccessful attempt to build gnucash with symbols, I resumed
working on what I was doing. I re-entered the dividend that caused the
trouble earlier, and tried to replicate my previous steps as accurately as
possible. No crash. The difference could be that the session that crashed
involved a fair amount of work prior to entering the dividend that was the
immediate cause of the crash. This time, there was no prior work. So the
stage might have been set earlier.

/Don

On 2/16/07, Donald Allen <donaldcallen at gmail.com> wrote:
>
> And I suppose it would be nice if I told you what I was doing when this
> happened. Similar deal as before: going through a brokerage statement and
> encountered a dividend on a newly-purchased stock. Entered the dividend
> against an existing income account (as a place-holder), added the new income
> account, went back to the dividend transaction, corrected the income
> account, tabbed, hit enter, and gnucash crashed.
>
> /Don
>
> On 2/16/07, Donald Allen <donaldcallen at gmail.com> wrote:
> >
> > 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}
> > >
> > >
> >
>