--On April 24, 2014 2:14:23 PM +0200 Geert Janssens
<janssens-ge...@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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
