Backticks don't work in Win32 multithreaded perl #8371
Comments
From krzysztofk@rocketmail.comIn short when I use fork under Win32 backticks don't sub run_p($) $|=1; Perl Info |
From @jkeenanOn Mon Mar 13 19:17:18 2006, krzysztofk wrote:
Reviewing older tickets this morning, I came across this one. Krzysztofk: It appears that by re-compiling Perl, you found a List: Could someone familiar with the current status of 'fork' on Win32 Thank you very much. |
|
The RT System itself - Status changed from 'new' to 'open' |
From @bulk88On Mon May 27 06:06:19 2013, jkeenan wrote:
___________________________________________________________________ C:\Documents and Settings\Owner\Desktop> All psuedo processes reached 20. Ran script 5 times, no freezes. Perl -- |
From @jkeenanOn Mon May 27 15:11:44 2013, bulk88 wrote:
[snip]
Let's give the OP and others seven days to comment, then close. Am Thank you very much. |
From krzysztofk@rocketmail.comThank you for running the tests. It did not freeze, but most of output from pseudo processes is missing. Thank you, ________________________________ On Mon May 27 06:06:19 2013, jkeenan wrote:
___________________________________________________________________ C:\Documents and Settings\Owner\Desktop> All psuedo processes reached 20. Ran script 5 times, no freezes. Perl -- |
From krzysztofk@rocketmail.comOK - compiling with -DUSE_RTL_POPEN solved my problem, but introduces some other. Perl compiled with that option did not pass the tests. The patch cannot be used with newer perls, because "critical section for files used by RTL" ( _pioinfo ) is no longer defined in Win32.c ________________________________ On Mon Mar 13 19:17:18 2006, krzysztofk wrote:
Reviewing older tickets this morning, I came across this one. Krzysztofk: It appears that by re-compiling Perl, you found a List: Could someone familiar with the current status of 'fork' on Win32 Thank you very much. |
From krzysztofk@rocketmail.compopen5a.patch*** win32.c.orig Tue Dec 18 04:47:08 2007
--- win32.c Tue Feb 05 13:43:37 2008
***************
*** 2979,2984 ****
--- 2979,2989 ----
*
* changed to return PerlIO* rather than FILE * by BKS, 11-11-2000
*/
+ #ifndef USE_RTL_POPEN
+ #ifdef MUTEX_LOCK
+ static CRITICAL_SECTION popen_mutex;
+ #endif
+ #endif
DllExport PerlIO*
win32_popen(const char *command, const char *mode)
***************
*** 3033,3038 ****
--- 3038,3045 ----
old_h = GetStdHandle(nhandle);
/* save current stdfd */
+ EnterCriticalSection(&popen_mutex);
+ EnterCriticalSection(&(_pioinfo(stdfd)->lock));
if ((oldfd = win32_dup(stdfd)) == -1)
goto cleanup;
***************
*** 3059,3064 ****
--- 3066,3072 ----
/* close saved handle */
win32_close(oldfd);
+ LeaveCriticalSection(&(_pioinfo(stdfd)->lock));
/* restore the old std handle (this needs to happen after the
* dup2(), since that might call SetStdHandle() too */
***************
*** 3077,3082 ****
--- 3085,3091 ----
}
/* we have an fd, return a file stream */
+ LeaveCriticalSection(&popen_mutex);
return (PerlIO_fdopen(p[parent], (char *)mode));
cleanup:
***************
*** 3092,3097 ****
--- 3101,3108 ----
OP_REFCNT_UNLOCK;
lock_held = 0;
}
+ LeaveCriticalSection(&(_pioinfo(stdfd)->lock));
+ LeaveCriticalSection(&popen_mutex);
return (NULL);
#endif /* USE_RTL_POPEN */
***************
*** 4790,4795 ****
--- 4801,4809 ----
#endif
MALLOC_INIT;
+ #ifndef USE_RTL_POPEN
+ InitializeCriticalSection(&popen_mutex);
+ #endif
module = GetModuleHandle("ntdll.dll");
if (module) {
*(FARPROC*)&pfnZwQuerySystemInformation = GetProcAddress(module, "ZwQuerySystemInformation");
|
From @bulk88On Tue May 28 17:25:06 2013, krzysztofk wrote:
Turns out I was wrong. There is a bug here. In my output I posted above -- |
From @tonycozOn Tue May 28 23:47:56 2013, bulk88 wrote:
It's possible I've fixed this in f06c882 which avoids modifying the global stdin/out handles when creating a popen() process. Tony |
From @tonycozOn Sun Mar 23 21:40:25 2014, tonyc wrote:
I tested with 64-bit 5.18.1 and blead@v5.19.8-291-ga27b5f5*. Neither locked up, but 5.18.1 did drop a lot of output. blead produced a lot more output and appears to have output a line for each iteration of the "child processes". I'll close this soon unless someone objects. Tony |
From @bulk88On Sun Mar 23 22:16:54 2014, tonyc wrote:
I got AP 5.10 to hang, it takes 3-8 trys before it hangs with a slightly tweaked script. sub run_p($) $|=1; ntdll.dll!_KiFastSystemCallRet@0() ntdll.dll!_RtlpWaitForCriticalSection@4() + 0x8c ntdll.dll!_KiFastSystemCallRet@0() ll child threads with this identical call stack ntdll.dll!_KiFastSystemCallRet@0() 7 child threads with this call stack ntdll.dll!_KiFastSystemCallRet@0() The perl OS process has a blocked cmd.exe child proc under it launched as "cmd.exe /x/d/c dir". IDK which perl fork thread is supposed to be reading from the cmd.exe process. I won't debug this very throughly but I'll look at it in another post, because, doing a perl -E" for(0..200){system('perl winhang.pl');}" with blead at http://perl5.git.perl.org/perl.git/commit/e9251c1a8f4944e6dceff5240d9e109ba075ff29 never hanged for me. -- |
From @bulk88The deadlock is like this, from outer most lock waiter, to lock owner. ntdll.dll!_KiFastSystemCallRet@0() at " print "Process $num iteration $_\n";" waits on CS held by thread ntdll.dll!_KiFastSystemCallRet@0() which is at " print "Process $num iteration $_\n";" I can't easily trace this any further since this is blocked IO now. Another kind of thread in the process ntdll.dll!_KiFastSystemCallRet@0() at line " `dir`;" is waiting on CS held by thread ntdll.dll!_KiFastSystemCallRet@0() which is at line " `dir`;" which is waiting on CS lock held by thread (we saw this thread above already) ntdll.dll!_KiFastSystemCallRet@0() -- |
From @bulk88On perl512 DEBUGGING (not sure if that is relevent), lock holder loop happened. thread ntdll.dll!_KiFastSystemCallRet@0() is at line " `dir`;" and waits on TID 11560 ntdll.dll!_KiFastSystemCallRet@0() is at line " `dir`;" and waits on TID 6824 ntdll.dll!_KiFastSystemCallRet@0() is at line " `dir`;" and waits on TID 11560 (a loop) I've seen this before on Perl RT and wrote this up, about CRT global "lock 11". https://rt-archive.perl.org/perl5/Ticket/Display.html?id=87410 Note the perl510 stacks showed a block on a WriteFile. On my 8 core machine (im not making any stacks from it), it takes NFORK = 60 to get a frequent (1 in 10 or better hangs) hang on Active non-debugging Perl 5.12. On the one that gave all the callstacks in this post and last is a 2 core machine. Strawberry 5.14 at NFORK 60 hangs on 8 core. ActivePerl 5.16 at NFORK 60 hangs on 8 core. ActivePerl 5.18 hangs at NFORK 60 on 8 core at NFORK 60. Perl random blead self compiled calling itself 5.19.4 hangs on WriteFile. Like the 5.10 call stacks. I can't rule out that some of the hangs are the lock 11 bug, or that both WriteFile and lock 11 randomly cause hangs. -- |
From @bulk88Running the sample script for 7 hours straight at 100% CPU with 5.19.10, it never hung , same when I rant it for 200 rounds with that 5.19.10 yesterday. I guess close it. -- |
|
@iabyn - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#38723 (status was 'resolved')
Searchable as RT38723$
The text was updated successfully, but these errors were encountered: