| Summary: | process loops forever when fatal signals are arriving quickly | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Philippe Waroquiers <philippe.waroquiers> |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ivosh, philippe.waroquiers |
| Priority: | NOR | ||
| Version: | 3.12 SVN | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | r16147 | Version Fixed In: | |
| Attachments: | reproducer and fix for process looping for ever when burst of fatal signals | ||
Fixed in revision 16140 Follow up revisions r16143 and r16147. |
Created attachment 102283 [details] reproducer and fix for process looping for ever when burst of fatal signals When fatal signal are arriving quickly, several threads might handle these fatal signals, and in parallel believe they have to vgkill the other threads and wait for the other threads to disappear. When this happens, the valgrind process loops forever 100% of cpu. This a bug that was already existing in 3.11 but in 3.11 was manifesting itself with several messages telling the process was being killed. The patch I will attach contains a regression test which very quickl reproduces the problem on ppc64. You might need some more loops on amd64. To reproduce the problem (with the untouched trunk, as the patch fixes it): while true do ../trunk/vg-in-place --tool=none none/tests/pth_2sig done And after some time, V loops at 100% of cpu. With the fix, the loop has done hundreds of runs without blocking, on amd64 and ppc64.