segfaults when running graphical reports

[Mike Alexander]

--On April 24, 2014 2:14:23 PM +0200 Geert Janssens 
<janssens-geert at telenet.be> 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:
> http://stackoverflow.com/questions/10588334/unix-background-process-s
> 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.

               Mike