|
From: LRN <lr...@gm...> - 2011-03-30 16:05:38
|
On 30.03.2011 18:48, Charles Wilson wrote: > On 3/30/2011 8:53 AM, Earnie wrote: >> Patches to resolve the issue in perl should >> be made upstream as well, correct? > And frankly, "solving" the problem -- rather than just papering over it > -- is going to be quite challenging. I had hoped that you would find the problem, but apparently you have failed. As did i. Because i've had difficulties in debugging perl with gdb. Because perl code is difficult to understand and is full of very perl-specific macros, abstractions and acronyms. And because i've tracked this phenomena across the call stack by adding lots of printf()s and discovered that the actual bug, i.e. interpretation of the (correct) return code & errno value, probably happens somewhere at the bottom of the binary stack (i've checked the script part up to the point where it calls close() builtin, the builtin appears to return 0, wrongly of course), close to the interpreter (either that, or the errno-evaluating part is hidden too well for me to find it), which might mean that the problem lies in some *other* piece of code that gets executed by the interpreter *after* the call to perl_something_IO_whatever_close(), but *before* script-level builtin close() returns. |