Oh yes, totally. The only question is what code is responsible.
I tracked it backwards from the point of failure (at which point the stack is completely screwed up) and found that the error definitely occurs somwhere after perl_do_span() calls win32_spawnvp() and before it return from the former.
Tracing it through at the binary level, CreateProcess() has been called and returned. As have GetExitCodeProcess(), a couple of calls to CloseHandle() to free up the PROCESS_INFORMATION structure. and at that point, the stack appears coherent. After that, win32_spawnvp makes a couple of calls to Perl_safesysfree() and one to MSCRT::strrchr() before trying to return to Perl_do_spawnvp() by which time the stack is corrupted.
The cynic in me guesses that it is the call to strrchr(), possibly looking for a null terminating byte that isn't found that is responsible, but that is pure speculation. Even if that is the cause, working out whether the CRT is responsible or the code that calls it is very difficult working at the machine code level, and I don't have a debug build of the code.
Either way, it doesn't seem (to me) to be the OS, but it will take somebody with better knowledge of the perl sources and better tools than I, to really make the determination.
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
| [reply] [Watch: Dir/Any] [d/l] |