Ticket #1154 (closed defect: fixed)
gsmd at 100% CPU (sigsegv-handling problem)
| Reported by: | mail@… | Owned by: | sean_chiang@… |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | gsmd | Version: | current svn head |
| Severity: | normal | Keywords: | |
| Cc: | buglog@…, tick@…, erin_yueh@…, sean_chiang@… | Blocked By: | |
| Blocking: | Estimated Completion (week): | ||
| HasPatchForReview: | PatchReviewResult: | ||
| Reproducible: |
Description
A few times now I have seen my recent MokoMakefile?-built gsmd (package version
0.1+svnr3759-r40) get stuck at 100% CPU. I ran 'strace -p' on its PID and saw
lots of the following:
Process 2353 attached - interrupt to quit
--- SIGSTOP (Stopped (signal)) @ 0 (0) ---
--- SIGSTOP (Stopped (signal)) @ 0 (0) ---
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
sigreturn() = ? (mask now [])
The gsmd.c code calls "signal(SIGSEGV, sig_handler);" (along with 4 other
signals), but the switch statement in the sig_handler() function does not have a
case for SIGSEGV. I do not know what initially triggered the problem, but it
looks like an un-handled segfault is causing the 100%-CPU looping.
Attachments
Change History
comment:6 Changed 5 years ago by erin_yueh@…
- Owner changed from erin_yueh@… to sean_chiang@…
hi Sean, please help to check this issue. Thanks! -erin
Changed 5 years ago by sean_chiang@…
- Attachment add-SIGSEGV-handler.patch added
have a
add case handle for SIGSEGV
comment:9 Changed 5 years ago by sean_chiang@…
- Status changed from assigned to closed
- Resolution set to fixed
Fix it with #1155
comment:10 Changed 5 years ago by mail@…
Regarding the patch - SIGSEGV represents an error condition, so it doesn't seem
right to exit with a return code of 0 in that case.
Changed 5 years ago by sean_chiang@…
- Attachment remove-register-of-SIGSEGV.patch added
remove register of SIGSEGV
