New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
skip tests that hangs on Windows XP #31
Conversation
I havent deeply followed this bug. How do I reproduce the hang? I want make myself a C callstack of the hang, and possibly fix it. |
@bulk88 Just run this test on Windows XP. |
From: mohawk2
I was hoping to get to testing I::C on XP myself, but (for various reasons) Cheers, |
You need to be more specific. |
in repo top-level dir. |
process tree
the EUMM code git blames to Perl-Toolchain-Gang/ExtUtils-MakeMaker@01f64a6 Hi Mohawk!
->cmd.exe /x/d/c chcp (end of tree)**CWD C:\sources\inline-c-pm_Inline_26fork.4232\build_26fork_t_0cc7\
update: neither does running manually running cmd.exe!_WaitProc@4 did the WaitForSingleObject on a process handle, using NTObjects tool, that process handle is "chcp.com" Notice "Win32 Process" is NULL. There is no chcp in Process Explorer or Task Manager after the hang. For comparison, here is the parent of chcp (a cmd.exe process), being dumped, it does have a "Win32 Process" pointer. I almost want to say, somehow chcp "exited" (or sent a exit message) in CSRSS/Win32 layer land, yet continue to exist, atleast as a kernel handle, in kernel mode or user-mode. I'm not sure if chcp is still running or not or has a thread inside it. I can't explain it ATM. It sounds like I'll have to start looking through my kernel mem dump or find a tool that can see NT Native processes, not just win32 processes. |
Nice work. Why is |
I have a suspicion the freeze is because of the ".lock" file next to config-MSWin32-x86-multi-thread-5.021006 file and "build" dir. I thought I debugged a similar/identical kernel hang a few weeks ago but I can't find it on google. http://www.perlmonks.org/?node_id=1008652 http://msdn.microsoft.com/en-us/library/windows/desktop/aa365203%28v=vs.85%29.aspx
later on in the procmon log
Notice chcp unlocking the file in kernel mode (since user mode already ended because of the process exit line) is the last thing the process did, or tried to do. I'll try to confirm this some way. |
I ****ing swear I debugged it couple months ago. That is how I knew it was the
So the question is, what made the .lock file? Did perl uses strictly p5p controlled code or an XS module to make that .lock file? I assume the handle for the .lock file was "inherited" by all child procs in the tree as shown in process explorer. When NT kernel tries to close all open handles in chcp proces, closing 1 handle hangs as shown. Note this is kernel mode, so whether the process is ever aware (AKA the handle number is in the process's user mode memory) that handle is open in its process is irrelevant for the kernel. This might be a bug in how perl marks handles to be "inherited" in CreateProcess child procs. IDK what happens on POSIX to comment what Win32 perl should be doing. I will next try to figure out the lock owner PID. |
The lock file is in order to implement what is being tested by test 26: deconflicting access to the DID directory (eg |
While looking for what could have locked the .lock file, I noticed something in the test/26fork.t process.
Child thread is at curcop "C:\sources\inline-c-pm\lib/Inline/C.pm"
kernel mode side of child thread stack
Notice 89966bf8 into IopSynchronousServiceTail. That is the file object. So now the question is, what is going on with the IRP and can I figure out what is blocking the IRP from completing. Device object/"driver" that got the IRP is
Not very interesting. update: update: So the bug is, in psuedofork Win32 perl, when you backticks (or I guess system() also), the child proc inherits the handles of all psuedo-procs. In this case, the child process is launched from main thread/psuedoproc that holds .lock and the child inherits that , the child proc also inherits the other .lock blocked in flock handle. At child proc exit, in kernel mode, the child proc blocks on the "other" .lock handle blocked in flock. The block then propagates to the main psuedoproc which is waiting for child proc to exit. Deadlock. lock dependency chain
On unix perl, the handle in the child psuedoproc (eghh, terms) would never be inherited by chcp process, so chcp wouldn't block, and the main psuedoproc wouldn't block. I have to manipulate inheritance settings now and see if it fixes the hang. |
The bug isolated into a test case
|
See ingydotnet#31 for bug description.
From: bulk88 Your demo works fine for me on Windows 7, perls 5.16.0 and 5.21.6. No This is perl 5, version 16, subversion 0 (v5.16.0) built for Cheers, |
See ingydotnet#31 for bug description. Even with this fix, the tests randomly fail due to a race condition where the .dll can not be deleted from disk while still loaded in a process.
See ingydotnet#31 for bug description. Even with this fix, the tests randomly fail due to a race condition where the .dll can not be deleted from disk while still loaded in a process.
See ingydotnet#31 for bug description.
See ingydotnet#31 for bug description.
See ingydotnet#31 for bug description.
See #31 for bug description.
See #31 for bug description.
Fixed |
No description provided.