Looking better at the code, the fileobject change isn't necessary. A simpler
fix is to just ignore and clear errors from _Py_DisplaySourceLine.
I´ll prepare a defect/patch
K
________________________________
Frá: python-dev-bounces+kristjan=ccpgames....@python.org
[python-dev-bounces+kristjan=ccpgames....@python.org] fyrir hönd Kristján Valur
Jónsson [krist...@ccpgames.com]
Sent: 16. júlí 2012 09:42
To: python-dev@python.org
Efni: [Python-Dev] early startup error reporting failure
Hi there.
I've been busy taking the current beta candidate and merging it into the
stackless repo.
As expected, things don't just go smoothly and there are the usual startup
errors, this being a rather intrusive patch and all that.
However, I found that early startup errors were not being reported correctly,
so I had do make some changes to fix that. I'm not sure these are the correct
fixes, so I'd like to start this here and see if anyone feels responsible.
Right: The initial error occurs here:
if (PyImport_ImportFrozenModule("_frozen_importlib") <= 0) {
Py_FatalError("Py_Initialize: can't import _frozen_importlib");
My problem was that the actual exception was not being reported along with the
FatalError message.
Digging around a bit, I found the cause here:
fileobject.c, PyFile_WriteString()
}
else if (!PyErr_Occurred()) {
That is, this function declines to write anything if there is an exception
present.
My quick and dirty fix was to remove this test and just print even with a
present exception. That fixes the issue.
But perhaps the _correct_ way is to suppress the exception higher up in the
callchain, which is this:
> python33_d.dll!PyFile_WriteString(const char * s, _object * f) Line 179 C
python33_d.dll!PyTraceBack_Print(_object * v, _object * f) Line 415 + 0x11
bytes C
python33_d.dll!print_exception(_object * f, _object * value) Line 1748 +
0x12 bytes C
python33_d.dll!print_exception_recursive(_object * f, _object * value,
_object * seen) Line 1889 C
python33_d.dll!PyErr_Display(_object * exception, _object * value, _object *
tb) Line 1913 C
python33_d.dll!sys_excepthook(_object * self, _object * args) Line 197 C
python33_d.dll!PyCFunction_Call(_object * func, _object * arg, _object * kw)
Line 99 + 0x46 bytes C
python33_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw)
Line 2149 + 0x48 bytes C
python33_d.dll!PyEval_CallObjectWithKeywords(_object * func, _object * arg,
_object * kw) Line 4584 C
python33_d.dll!PyErr_PrintEx(int set_sys_last_vars) Line 1686 + 0x12 bytes C
python33_d.dll!Py_FatalError(const char * msg) Line 2358 C
Perhaps error should be fetched and restored in PyTraceback_Print(), since it
already does some exception juggling, obviously assuming that an exception
state can be present that it is worthwhile to preserve.
Ok, then I came to the second issue.
When printing the tracebacks, this early in the process, I hit upon this code,
in
traceback.c, tb_displayline(), I made this change (line 344):
- return _Py_DisplaySourceLine(f, filename, lineno, 4);
+ /* ignore IO errors here, IO may not be ready yet */
+ if ( _Py_DisplaySourceLine(f, filename, lineno, 4) )
+ PyErr_Clear();
+ return err;
This early in the process, IO cannot be imported so it is impossible to output
source line. The source line output is a "bonus" feature anyway and we
shouldn't, IMHO, fail outputting tracebacks if we cannot read the code.
The actual failure was importing the IO library. Perhaps an alternative fix,
then, is to fix the _Py_DisplaySourceLine() so that it deals with failure to
import IO in the same way as failure to read the file, i.e. just returns a
"success" value of 0.
With these changes, I was able to successfully output the error. Hopefully I
will be able to debug it too :)
Any thoughts?
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
