Re^2: POE / Win32 / select ?

[soliplaya]

Thanks for the tip. I looked at the various pages you pointed out, and it seemed to me that none of them really corresponded to what I am doing. But I figured, what the heck, by now I am ready to try anything, so I did update to Strawberry Perl v 5.20.3 and tried again. The result changes slightly, in the sense that now that last message the program puts in the log is :

2016/10/01-12:13:37 I process(): starting child with command [E:\MIRA\strawberry\perl\bin\perl C:/EFS/bin/MiraAdd_medfolio.pl .. renoved .. "E:\MIRA\Migration\medfolio_test\NxExport\output\Alles/FOLDER_41486093_177671_12/OVERVIEW.xml"]

and I do not see the "select:" error message anymore. But the program stops just as dead in its tracks. In the Windows Application Event log, the message also changed slightly, and now says :

Application Failure perl.exe 5.20.3.3 in encoding.xs.dll 0.0.0.0 at offset 000014ea

So it is no longer "encoding.dll", but instead "encoding.xs.dll". Any other ideas/suggestions/questions ?

[Anonymous Monk]

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

[soliplaya]

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.