segfaults when running graphical reports

John Ralls jralls at
Sun Apr 13 12:56:38 EDT 2014

On Apr 13, 2014, at 8:41 AM, Thomas Klausner <tk at> wrote:

> Hi John!
> On Sun, Apr 13, 2014 at 08:18:17AM -0700, John Ralls wrote:
>> On Apr 13, 2014, at 12:35 AM, Thomas Klausner <tk at> wrote:
>>> Hi!
>>> I'm using gnucash-2.6.3 from pkgsrc on NetBSD-6.99.40/amd64.
>>> I see two recent changes compared to 2.4.13, the previous version in
>>> pkgsrc.
>>> The first: If I start gnucash without a terminal or in the background,
>>> it doesn't finish startup. When started in the background, I see (with
>>> zsh):
>>>> gnucash &
>>> [1] 7303
>>> [1]  + suspended (tty output)  gnucash
>>> When I put it in the foreground again, it continues starting
>>> successfully. This seems to happen during the splash screen, the last
>>> thing that's displayed in the progress text at the bottom is
>>> "gnucash/python". Perhaps this is a problem with a python module, but
>>> how do I find out which?
>> The problem is whatever output is going to the terminal. What is it?
>> Note that you can work around the problem with a redirect: guncash > /dev/null 2>&1 &
> The only thing that's on stdout is "Found Finance::Quote version 1.18"
> and that's been there forever; i.e. this was also there when I still
> could start gnucash in the background. Nothing else is going to the
> terminal (to make sure, I just re-tried with redirecting stdout and
> stderr). Also, usually backgrounding a process doesn't cause issues
> with output, it's just written anyway. For example "cat filename &"
> works fine. So I'm confused why this stops the startup in this case.
>>> The worse problem I have is when I try to run a graphical report (e.g.
>>> Income & Expense / Expense barchart) I get a segfault:
>>> zsh: segmentation fault (core dumped)  gnucash
>>> The backtrace is not very helpful, even when compiled with '-g -O0':
>>> (gdb) bt
>>> #0  0x00007f7f87800a0c in ?? ()
>>> #1  0x00007f7f857fe088 in ?? ()
>>> #2  0x00007f7ff6a9efc0 in ?? ()
>>> #3  0x00007f7feb1641a8 in ?? ()
>>> #4  0x00007f7ff6a9e1c0 in ?? ()
>>> #5  0x00007f7fee3be8e8 in ?? ()
>>> #6  0x00007f7feecf9c00 in WTF::central_cache () from /usr/pkg/lib/
>>> #7  0x0000000000000000 in ?? ()
>>> I have webkit-gtk-1.10.2 installed if that matters.
>> That's because the crash isn't in GnuCash. You need to get the debug symbols for more packages. I'd start with glib, gtk, and webkit and see if that fills in the blanks or provides clues to what other symbols you might need.
> Can you tell me more about how displaying the graphs is supposed to
> work? gnucash creates a javascript file and then does what to display
> it? I understand you're saying that it's not a gnucash problem, so
> perhaps we can separate it from gnucash. Though I do get a
> gnucash.core file.
> Thomas

Reports write out an html page, and graphical ones include javascript to make the graphs. The result is passed to WebKitGtk to render and display in a new GdkWindow, which by default is in turn wrapped by a notebook page.

The core is "gnucash.core" because gnucash was the running program. If core files were named for the shared libraries where the crash occurred it would be pretty confusing.

It may well be a GnuCash problem, it's just that the actual crash isn't occurring in GnuCash code. In order to get an intelligible stack trace you need the debugging symbols for the shared library where the crash occurred and any others that might be in the stack at the time of the crash. In Linux distros the images aren't completely stripped, but the symbols are distributed in a separate package. If that's not the case with BSD you may have to get the source packages and build them yourself.

John Ralls

More information about the gnucash-devel mailing list