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 ?
| [reply] |
| [reply] |
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] |