From: Jonathan M. <jon...@gm...> - 2011-06-27 11:23:20
|
Hi all, Since I last built a release of BPBible with py2exe, I added support for using faulthandler, a library to catch segmentation faults and actually give a decent stack trace for them (see http://pypi.python.org/pypi/faulthandler/). This seemed to work really well and do just what was expected. However, I discovered that it doesn't work with Py2exe (or at least not the version that I have with Python 2.6). The reason why is that faulthandler uses the fileno() method on standard input or standard output, and this doesn't exist in the dummy file handlers installed by py2exe. Has anyone come across this before? Is there an easy solution? Thanks, Jon |
From: Daryl T. <dt-...@ha...> - 2011-06-27 18:02:31
|
On 27/06/11 20:52, Jonathan Morgan wrote: > (see http://pypi.python.org/pypi/faulthandler/). ... > The reason why is that faulthandler > uses the fileno() method on standard input or standard output, and this > doesn't exist in the dummy file handlers installed by py2exe. I'd just be guessing (as I don't use this library), but to quote from the front page of the URL above - "Start your graphical applications in a terminal and run your server in foreground to see the traceback, or pass a file to faulthandler.enable()." Further down the page it gives some info on the parameters passed to enable(). Or am I missing something in the initial description of the problem? -- Regards, Daryl Tester Handcrafted Computers Pty. Ltd. |
From: Jonathan M. <jon...@gm...> - 2011-06-28 02:09:16
|
Hi Daryl, On Tue, Jun 28, 2011 at 3:44 AM, Daryl Tester < dt-...@ha...> wrote: > On 27/06/11 20:52, Jonathan Morgan wrote: > > > (see http://pypi.python.org/pypi/faulthandler/). > ... > > The reason why is that faulthandler > > uses the fileno() method on standard input or standard output, and this > > doesn't exist in the dummy file handlers installed by py2exe. > > I'd just be guessing (as I don't use this library), but to quote from > the front page of the URL above - "Start your graphical applications > in a terminal and run your server in foreground to see the traceback, > or pass a file to faulthandler.enable()." Further down the page it > gives some info on the parameters passed to enable(). > You are correct about that (I hadn't looked back at the page since including it a couple of months ago). However, I was wanting to use stderr for the log so that Py2exe would automatically catch it and write to the standard Py2exe error log. Otherwise I presumably have to add similar log writing functionality to what Py2exe has (which I know checks permissions and does a few other things). Is there any problem with the Py2exe stderr having a fileno()? Is it just because it is a dummy file and so it doesn't make sense having a fileno()? Thanks, Jon |
From: Mark H. <ski...@gm...> - 2011-06-28 02:19:14
|
On 28/06/2011 12:08 PM, Jonathan Morgan wrote: > to the standard Py2exe error log. Otherwise I presumably have to add > similar log writing functionality to what Py2exe has (which I know > checks permissions and does a few other things). Is there any problem > with the Py2exe stderr having a fileno()? Is it just because it is a > dummy file and so it doesn't make sense having a fileno()? It is mainly because the stderr log file isn't created until the first write. As a workaround, you could simply reassign sys.stderr to sys.__stderr__ - but obviously you then lose the magic redirection yourself. Or just reassign sys.stderr to an object more of your liking (and assuming nothing has written to stderr by the time you do this, no logfile will be created.) Mark |
From: Daryl T. <dt-...@ha...> - 2011-06-28 02:31:40
|
On 28/06/11 11:38, Jonathan Morgan wrote: > However, I was wanting to use stderr for the > log so that Py2exe would automatically catch it and write to the standard > Py2exe error log. Otherwise I presumably have to add similar log writing > functionality to what Py2exe has (which I know checks permissions and does a > few other things). I'm not sure it does that. I think the relevant class you're looking for is "Stderr" in py2exe\boot_common.py, and it just appears to be opening a log file named sys.executable + ".log" upon initial write (I'm looking at py2exe 0.6.9 here). > Is there any problem with the Py2exe stderr having a > fileno()? Is it just because it is a dummy file and so it doesn't make > sense having a fileno()? Probably a leaky abstraction - I'm not sure why the faulthandler module is concerning itself over the file descriptor when all it should be doing is calling the write() method (well, looking at the faulthandler source it's in C, and they're using puts(), so that'd be it). I was thinking that you could dummy up a fileno() on Stderr to create a file when called, but the advantage of the py2exe logger is that it will create the file when needed, not at start up (so you're not littered with empty log files for every run of your program). I can't think of a way to get around this without modifying faulthandler. Sorry. -- Regards, Daryl Tester Handcrafted Computers Pty. Ltd. |
From: Daryl T. <dt-...@ha...> - 2011-06-28 02:41:11
|
On 28/06/11 12:01, Daryl Tester wrote: > I was thinking that you could dummy up a fileno() on Stderr to create > a file when called, but the advantage of the py2exe logger is that it > will create the file when needed, not at start up (so you're not littered > with empty log files for every run of your program). I was also thinking of perhaps doing something cunning with StringIO, but on closer examination you'd be in the same predicament - it doesn't have fileno() either. And faulthandler may not want to use an object's write() method, given that it may be invoked due to an interpreter crash ... -- Regards, Daryl Tester Handcrafted Computers Pty. Ltd. |