segfaults when running graphical reports

Mike Alexander mta at
Thu Apr 24 14:16:18 EDT 2014

--On April 24, 2014 2:14:23 PM +0200 Geert Janssens 
<janssens-geert at> wrote:

> Thank you for digging deeper into this issue.
> I hadn't been following this thread in detail but the attached patch
> caught my (maintainer's) attention.
> Personally I'm not too fond of adding this workaround into gnucash.
> Your  conversation with the readline upstream indicates this is not
> an issue  that originates in gnucash.
> The way I understand your message is that GnuCash receives a SIGTTOU
> signal and halts. It receives this signal because it wants to write
> to  standard output while being backgrounded.
> Some googling got me to this page:
> topped-abnormally
> The answer explains that SIGTTOU is emitted depending on the settings
> of  the current terminal.
> You can test this for your terminal with the command
> stty -a
> and check if tostop is set.
> I could reproduce his halt by running
> stty tostop
> gnucash &
> in my bash session on Fedora 20 (which uses readline 6.2). In my case
> it  did halt when "Finance::Quote" was displayed in the splash screen.
> Did your upgrade to gnucash 2.6.3 happen around the same time of a
> zsh  update ?

I've seen this behavior for months, ever since the Python support was 
added, I think.  tostop isn't set in my terminal session.  I looked at 
a backtrace when it was stopped and I suspect the problem is this (from 
the page you linked to):

> The process attempted to change the terminal modes with tcsetattr(3)
> or an equivalent ioctl. (These are the same modes shown by stty.)
> This generates SIGTTOU regardless of the current state of the tostop
> flag.

When Python initializes READLINE, it does something to trip over this.


More information about the gnucash-devel mailing list