| Summary: | SIGABRT and SIGSEGV in epoll_wait during wl_event_loop_dispatch | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | Anu Reddy <anasuyax.r.nannuri> |
| Component: | weston | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | VERIFIED NOTABUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
gdb-backtrace1
gdb-backtrace2 |
||
|
Description
Anu Reddy
2014-04-15 00:08:09 UTC
Created attachment 97372 [details]
gdb-backtrace1
Created attachment 97373 [details]
gdb-backtrace2
What would you expect to happen, when a compositor receives a SEGV or ABRT? What should work differently than it does now? I mean, what is the problem you see here? To me it seems like a process getting a SEGV or ABRT should die, so I'm not sure what the bug here is. Correct. SIGSEGV and SIGABRT are meant to trigger a segmentation fault and abort, respectively. The point of testing these signals is to ensure weston or weston-launch exit codes reflect this appropriately. It would be bad if the exit code returned 0, for instance. I just remembered that weston does have handlers for these two signals. They both execute on_caught_signal(), around http://cgit.freedesktop.org/wayland/weston/tree/src/compositor.c#n3885 which then raises SIGTRAP. This might affect the process exit code, but surely it won't exit with status 0, right? But the exit code might not reflect ABRT or SEGV properly. Not sure if that could be a problem. SIGTRAP, SIGABRT and SIGKILL signals are exiting with 'non zero' exit code. But when weston receives SIGABRT and SIGTRAP signals, I see below message on tty. Trace/breakpoint trap (core dumped) – (weston)_main I mean.... SIGSEGV, SIGABRT and SIGKILL signals are exiting with 'non zero' exit code. But when weston receives SIGABRT and SIGSEGV signals, I see below message on tty. Trace/breakpoint trap (core dumped) – (weston)_main (In reply to comment #6) > SIGTRAP, SIGABRT and SIGKILL signals are exiting with 'non zero' exit code. > But when weston receives SIGABRT and SIGTRAP signals, I see below message on > tty. Trace/breakpoint trap (core dumped) – (weston)_main (In reply to comment #5) > I just remembered that weston does have handlers for these two signals. They > both execute on_caught_signal(), around > http://cgit.freedesktop.org/wayland/weston/tree/src/compositor.c#n3885 which > then raises SIGTRAP. > > This might affect the process exit code, but surely it won't exit with > status 0, right? But the exit code might not reflect ABRT or SEGV properly. > Not sure if that could be a problem. Right. As long as weston exits with any non-zero status for these signals, then it shouldn't be a problem in most cases. Basically, when doing test automation we want to be sure that a weston crash is detectable with a non-zero exit code so that the test result can reflect that correctly. (In reply to comment #7) > I mean.... > > SIGSEGV, SIGABRT and SIGKILL signals are exiting with 'non zero' exit code. > But when weston receives SIGABRT and SIGSEGV signals, I see below message on > tty. > > Trace/breakpoint trap (core dumped) – (weston)_main Yes, that is the current intended behaviour. If you read the comment in on_caught_signal(), you'll see why it's there. If we were to re-raise the SEGV or ABRT, using gdb might be harder. OTOH, we could have a command line switch for choosing gdb-friendly operation. But, like Artie said, until someone sees a practical problem here, things should be ok as is. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.