-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Test failure baseservices/exceptions/simple/ParallelCrash/ParallelCrash.sh #72755
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Failed again in: runtime-coreclr gcstress-extra 20220731.1 Failed Test:
Error message:
|
@mikem8361 This test intentionally crashes and then it seems to hang on the
|
It looks like it is blocked in the waitpid at line 2459. We are waiting for createdump to finish generating the core dump and exit. Is there a createdump process still around? Maybe createdump is taking too long to finish. Is the crashing process large?
2458 int wstatus = 0;
2459 int result = waitpid(childpid, &wstatus, 0);
2460 if (result != childpid)
2461 {
…>libpthread_2_27+0x11d5c
>libcoreclr!PROCCreateCrashDump+0x338 [/__w/1/s/src/coreclr/pal/src/thread/process.cpp @ 2460]
>libcoreclr!PROCCreateCrashDumpIfEnabled+0x5d0 [/__w/1/s/src/coreclr/pal/src/thread/process.cpp @ 2637]
|
Sorry, I was looking at the PR diff for the line numbers not the current process.cpp source. You are right that line 2460 in the current source is the close(parent_pipe). I need to investigate why close on this pipe hangs. |
I think you are actually correct, because those line numbers are for the 20220731.1 build. The crashing process should be small as we run this test individually. |
If the stack trace is from a core dump generated by createdump, the crashing thread will be waiting at that point on the waitpid. Isn't the failure from whatever called the FailFast? I don't think this issue is createdump related. |
This test intentionally calls
The question is why the test hangs indefinitely after that call:
#69663 was merged on May 26th. According to the table above, the test started to time out on May 29th ( |
Tagging subscribers to this area: @tommcdon Issue DetailsRun: runtime-coreclr gcstress-extra 20220723.1 Failed test:
Error message:
|
Mike, I see this in an old log:
Looks like it comes from libunwind. |
* Add logging callback to DAC EnumMemoryRegion API Add the ICLRDataEnumMemoryRegionsLoggingCallback interface so createdump can receive logging from the EnumMemoryRegion API. Add logging to MethodTable EnumMemoryRegion for invalid EEClass/Canonical MT. * Add checked build logging after waitpid for createdump to help diagnose issue #72755. * Add more DAC logging * Code review feedback Co-authored-by: Juan Hoyos <[email protected]>
How can I see more recent failures (with a runtime with my new logging) with this test? |
Here's a runfo query that should provide the latest failures: https://runfo.azurewebsites.net/search/tests/?q=started%3A%7E7+definition%3A662+name%3AParallelCrash.sh. You can change the timeframe by altering "started" to filter within a specific date range. |
According to kusto, last failure was 2022-08-07T08:53:38.06Z, so nothing since your PR went in. |
Very likely a duplicate of #57621. Please reopen if you hit this again. |
Reopening, I did not check dates properly. |
This hasn't reproed since 8/7; moving to future until we have something to make it actionable. |
ParallelCrash - no failures in the last 3 weeks, closing. |
Run: runtime-coreclr gcstress-extra 20220723.1
Failed test:
Error message:
The text was updated successfully, but these errors were encountered: