segfaults when running graphical reports

John Ralls jralls at ceridwen.us
Thu Apr 24 18:29:57 EDT 2014


On Apr 24, 2014, at 3:05 PM, Mike Alexander <mta at umich.edu> wrote:

> --On April 24, 2014 2:48:29 PM -0700 John Ralls <jralls at ceridwen.us> wrote:
> 
>> It disables calling python from inside of GnuCash, but I don’t
>> think we actually do that anywhere. It shouldn’t affect using the
>> GnuCash API from a python program.
> 
> I guess that's ok for now, but we might want to call it from inside GnuCash someday.  It seems to me that the other workaround, to ignore SIGTTOU, is better.  You could just ignore it while initializing Python if you want to limit the possibility of ignoring one you care about.
> 
> Also, has anyone tried to use a Python script that access GnuCash with the patch to not initialize the Python module in gnucash-bin.c applied? I didn't and it seems to me that calling GnuCash from a Python script might trigger the SIGTTOU hang.  Won't init.py be executed then?  If so it will probably hang when it imports pycons.console.
> 
> Another workaround would be to remove the console support from init.py. It's currently not used, but it still imports pycons.console which triggers the hang.

Good thought. That’s very likely the source of the problem. In fact, just rearranging the readline stuff in pycons/console.py so that it isn’t invoked automatically might do it; maybe check that sys.stdin is defined if we can do so without firing a SIGTTOU.

But as a general statement we shouldn’t even be starting a Python interpreter unless the user specifically asks for it with a menu selection or a command-line option or something, and there should be a separate selection to start a console session. That’s a lot of pointless overhead. GnuCash has enough going on without that for help!

Regards,
John Ralls




More information about the gnucash-devel mailing list