[Python-Dev] early startup error reporting failure

[Kristján Valur Jónsson]

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.com at python.org [python-dev-bounces+kristjan=ccpgames.com at python.org] fyrir hönd Kristján Valur Jónsson [kristjan at ccpgames.com]
Sent: 16. júlí 2012 09:42
To: python-dev at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120716/e4c39496/attachment.html>