Steve Peters wrote:
The code would also be useful to the Perl core and, I assume, to POE as
test cases to ensure that this bug does not resurface.
I've seen this bug at my day job The "offending" perl code, in general,
provides very little clue as to the cause of the problem. We're looking
at a complex interaction of perl5.8, poe, and log4perl deep under the
covers. We cleared our first run in with the bug at work by removing a
goto of all things.
POE has a very long history and exposing fun and psychotic bugs in the
perl core. We push perl in odd places and that's why people like Andreas
run POE's test suite when testing new perls. modperl, PPI, and several
other modules are used in a similar fashion.
From what I've read and seen of the bug, I think the only "test" that's
going to help our users is a documentation note discussing the
interaction of these factors on perl5.8.7. It is possible that p5p will
come up with some crazy fix we can use the stop the problem (ie the
CRIMSON_HACK) but I think that's probably a longshot with this bug.
Agreed. Better still a perl built with the Configure option
-Doptimize="-g" would be helpful to produce a coredump with debugging
symbols to see where the errors are occurring.
More importantly, add -O0.
sungo.
|
Try Searching:
servers, voip, java, networking, microsoft ...
|
|
|
| 
