This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Errors in site.py not reported properly
Type: Stage:
Components: None Versions: Python 3.0
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Rhamphoryncus, christian.heimes, gvanrossum
Priority: normal Keywords:

Created on 2007-08-09 21:37 by Rhamphoryncus, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (4)
msg32615 - (view) Author: Adam Olsen (Rhamphoryncus) Date: 2007-08-09 21:37
(Ignore the p3yk dir name.  This has been updated to the py3k branch.)

rhamph@factor:~/src/python-p3yk/build$ make
object  : 
type    : TypeError
refcount: 4
address : 0x8239f0c
lost sys.stderr
make: *** [sharedmods] Error 1

The root cause is that (due to some local modifications) site.py failed to load and gave an error.  This can be easily duplicated by opening up Lib/site.py:main and putting 1/0 on the first line.

However, the ZeroDivisionError that should cause never gets printed.  Python/pythonrun.c:initsite attempts to retrieve sys.stderr, which fails because site.py never got a chance to install it (!), then passes the NULL file object pointer to PyFile_WriteString, which turns that into a new exception (replacing the old one).  initsite ignores the return value indicating the exception, instead clearing it, and the interpreter continues to load, no one the wiser.

Several other exceptions may happen and get squashed, I'm not sure.

Eventually, Python/sysmodule.c:sys_excepthook calls Python/pythonrun.c:PyErr_Display, which attempts to retrieve sys.stderr, and failing that calls _PyObject_Dump() on the exception (explaining the weird message).  Oddly, there's a *second* if statement, which then prints the "lost sys.stderr" line.


Possible remedies:
1.  PyErr_Display's dump message is not very clear.
2.  initsite should go directly to stderr if it can't retrieve sys.stderr.  Alternatively, since site.py is now more important, it could be changed into a fatal error.  Yet another option is to explicitly check for sys.stderr even on success and make that alone into a fatal error.
3.  The error printing APIs could be modified to internalize the stderr retrieval.  Upon failure they could print a brief "stderr unavailable; original exception was ..." message.
msg32616 - (view) Author: Adam Olsen (Rhamphoryncus) Date: 2007-08-10 18:19
Following up on the possible remedies, I'm thinking PySys_WriteStderr could be extended to take file object as the first argument, and if null it writes to low-level stderr instead.  That way the callers can add the message about "lost sys.stderr" themselves, rather than it being interspersed in their output.
msg32617 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2007-08-19 13:56
I run into trouble with stderr myself and I agree that the problem should be resolved somehow by falling back to the file descriptor 2 (stderr). The current implementation makes it unnecessarily hard to debug problems in site.py, io.py and possible also codecs.*.
msg56978 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-10-30 18:56
Fixed by Christian Heimes's patch, see issue 1352 and issue 1329.
History
Date User Action Args
2022-04-11 14:56:25adminsetgithub: 45293
2008-01-06 22:29:46adminsetkeywords: - py3k
versions: Python 3.0
2007-10-30 18:56:38gvanrossumsetstatus: open -> closed
resolution: fixed
messages: + msg56978
nosy: + gvanrossum
2007-08-30 00:23:36gvanrossumsetversions: + Python 3.0
2007-08-09 21:37:51Rhamphoryncuscreate