<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle">P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body fPStyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">
<p>Looking better at the code, the fileobject change isn't necessary. A simpler fix is to just ignore and clear errors from _Py_DisplaySourceLine.</p>
<p>I´ll prepare a defect/patch</p>
<p> </p>
<p>K</p>
<div style="FONT-FAMILY: Times New Roman; COLOR: #000000; FONT-SIZE: 16px">
<hr tabindex="-1">
<div style="DIRECTION: ltr" id="divRpF821826"><font color="#000000" size="2" face="Tahoma"><b>Frá:</b> python-dev-bounces+kristjan=ccpgames.com@python.org [python-dev-bounces+kristjan=ccpgames.com@python.org] fyrir hönd Kristján Valur Jónsson [kristjan@ccpgames.com]<br>
<b>Sent:</b> 16. júlí 2012 09:42<br>
<b>To:</b> python-dev@python.org<br>
<b>Efni:</b> [Python-Dev] early startup error reporting failure<br>
</font><br>
</div>
<div></div>
<div>
<div style="FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZE: 10pt">
<p>Hi there.</p>
<p>I've been busy taking the current beta candidate and merging it into the stackless repo.</p>
<p>As expected, things don't just go smoothly and there are the usual startup errors, this being a rather intrusive patch and all that.</p>
<p> </p>
<p>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.</p>
<p> </p>
<p>Right: The initial error occurs here:</p>
<font size="2" face="Consolas"><font size="2" face="Consolas">
<p></font></font><font color="#0000ff" size="2" face="Consolas"><font color="#0000ff" size="2" face="Consolas"><font color="#0000ff" size="2" face="Consolas">if</font></font></font><font size="2" face="Consolas"><font size="2" face="Consolas"> (PyImport_ImportFrozenModule(</font></font><font color="#a31515" size="2" face="Consolas"><font color="#a31515" size="2" face="Consolas"><font color="#a31515" size="2" face="Consolas">"_frozen_importlib"</font></font></font><font size="2" face="Consolas"><font size="2" face="Consolas">)
<= 0) {</p>
<p> Py_FatalError(</font></font><font color="#a31515" size="2" face="Consolas"><font color="#a31515" size="2" face="Consolas"><font color="#a31515" size="2" face="Consolas">"Py_Initialize: can't import _frozen_importlib"</font></font></font><font size="2" face="Consolas"><font size="2" face="Consolas">);</p>
</font></font>
<p>My problem was that the actual exception was not being reported along with the FatalError message.</p>
<p> </p>
<p>Digging around a bit, I found the cause here:</p>
<p>fileobject.c, PyFile_WriteString()</p>
<p> }<br>
else if (!PyErr_Occurred()) {<br>
</p>
<p>That is, this function declines to write anything if there is an exception present.</p>
<p>My quick and dirty fix was to remove this test and just print even with a present exception. That fixes the issue.</p>
<p>But perhaps the _correct_ way is to suppress the exception higher up in the callchain, which is this:</p>
<p>> python33_d.dll!PyFile_WriteString(const char * s, _object * f) Line 179 C<br>
python33_d.dll!PyTraceBack_Print(_object * v, _object * f) Line 415 + 0x11 bytes C<br>
python33_d.dll!print_exception(_object * f, _object * value) Line 1748 + 0x12 bytes C<br>
python33_d.dll!print_exception_recursive(_object * f, _object * value, _object * seen) Line 1889 C<br>
python33_d.dll!PyErr_Display(_object * exception, _object * value, _object * tb) Line 1913 C<br>
python33_d.dll!sys_excepthook(_object * self, _object * args) Line 197 C<br>
python33_d.dll!PyCFunction_Call(_object * func, _object * arg, _object * kw) Line 99 + 0x46 bytes C<br>
python33_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw) Line 2149 + 0x48 bytes C<br>
python33_d.dll!PyEval_CallObjectWithKeywords(_object * func, _object * arg, _object * kw) Line 4584 C<br>
python33_d.dll!PyErr_PrintEx(int set_sys_last_vars) Line 1686 + 0x12 bytes C<br>
python33_d.dll!Py_FatalError(const char * msg) Line 2358 C<br>
</p>
<p>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.</p>
<p> </p>
<p>Ok, then I came to the second issue.</p>
<p>When printing the tracebacks, this early in the process, I hit upon this code, in
</p>
<p>traceback.c, tb_displayline(), I made this change (line 344):</p>
<p>- return _Py_DisplaySourceLine(f, filename, lineno, 4);<br>
+ /* ignore IO errors here, IO may not be ready yet */<br>
+ if ( _Py_DisplaySourceLine(f, filename, lineno, 4) )<br>
+ PyErr_Clear();<br>
+ return err;</p>
<p> </p>
<p>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.</p>
<p> </p>
<p>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.</p>
<p> </p>
<p>With these changes, I was able to successfully output the error. Hopefully I will be able to debug it too :)</p>
<p> </p>
<p>Any thoughts?</p>
</div>
</div>
</div>
</div>
</body>
</html>