Re^3: POE / Win32 / select ?

Hi,

Maybe try newer release

Also maybe try to glean some hints from Bug #41121 for perl5: segmentation fault Running binmode(STDOUT, ":encoding(utf8)") with ithreads

And maybe , if you can narrow it to small test case (like in above report) send a report via perlbug

Comment on Re^3: POE / Win32 / select ?

Replies are listed 'Best First'.
Re^4: POE / Win32 / select ? by soliplaya (Beadle) on Oct 03, 2016 at 13:10 UTC
Solved (kind of). So thanks for motivating me to persist. With StrawberryPerl 5.24.0, the crash in encoding.dll / encoding.xs.dll does not happen anymore. No lower version will do (tried 5.18, 5.20, 5.22.3; all crash). (The reason for which I write "kind of" above is that on the system where this happens, there are a bunch of other programs running since years under ActivePerl 5.10.x, so that installing another version just for this one program was a bit more work than I bargained for initially.) I have also come to the conclusion that the IO::Pipely code section which I mentioned in my first post, has probably nothing to do with that particular crash issue after all. It was just coincidence that this IO::Pipely code is called by POE::Wheel::Run just before starting the "Wheel" sub-process. The fact that my program crashed with the "encoding" dll's however, kind of broadens the scope of what I've seen in these previous bug reports, because I don't do anything in the Wheel sub-process that resembles what I've seen mentioned there. I just open a file with an ":encoding()", but it is not STDOUT/STDERR/STDIN. But maybe it is POE::Wheel::Run in this case which triggers the problem, because it does "play around" with these filehandles. Separately, I seem to have found a strange kind of random issue in the IO::Pipely module when used under Windows, but maybe I will comment on this in a separate post. Thanks for the help in any case. Without your hints, I would never have thought to look in that direction. I am still puzzled why another program on that same server, also using POE and the exact same sequence to start another similar sub-process, is running and has been running for several years without apparently ever encountering the same issue.	[reply]

Replies are listed 'Best First'.

Re^4: POE / Win32 / select ?
by soliplaya (Beadle) on Oct 03, 2016 at 13:10 UTC

Solved

With StrawberryPerl 5.24.0, the crash in encoding.dll / encoding.xs.dll does not happen anymore. No lower version will do (tried 5.18, 5.20, 5.22.3; all crash).

(The reason for which I write "kind of" above is that on the system where this happens, there are a bunch of other programs running since years under ActivePerl 5.10.x, so that installing another version just for this one program was a bit more work than I bargained for initially.)

I have also come to the conclusion that the IO::Pipely code section which I mentioned in my first post, has probably nothing to do with that particular crash issue after all. It was just coincidence that this IO::Pipely code is called by POE::Wheel::Run just before starting the "Wheel" sub-process.

The fact that my program crashed with the "encoding" dll's however, kind of broadens the scope of what I've seen in these previous bug reports, because I don't do anything in the Wheel sub-process that resembles what I've seen mentioned there. I just open a file with an ":encoding()", but it is not STDOUT/STDERR/STDIN. But maybe it is POE::Wheel::Run in this case which triggers the problem, because it does "play around" with these filehandles.

Separately, I seem to have found a strange kind of random issue in the IO::Pipely module when used under Windows, but maybe I will comment on this in a separate post.

Thanks for the help in any case. Without your hints, I would never have thought to look in that direction.

I am still puzzled why another program on that same server, also using POE and the exact same sequence to start another similar sub-process, is running and has been running for several years without apparently ever encountering the same issue.

[reply]