Changes between Initial Version and Version 4 of Ticket #18549


Ignore:
Timestamp:
Aug 11, 2023, 6:49:59 AM (9 months ago)
Author:
nielx
Comment:

Thanks PulkoMandy. You were correct in that one could resume the process and get the correct outcome. I guess it was a case of user error (the user is me!). After reviewing the code (thanks waddlesplash), it is clear that the debugger() call only pauses the execution, not terminates it.

Arguably it is more of a UI problem than a bug in our POSIX implementation. Moving priority to low and even contemplating whether or not to change this into an enhancement.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #18549

    • Property Component System/POSIX → System/libroot.so
    • Property Priority normal → low
    • Property Summary waitpid() does not capture signal of a terminated child process other than SIGKILLTHR → abort() calls debugger when no signal handler for SIGABRT is set, inviting the user to kill the app with SIGKILLTHR rather than terminate 'normally' with SIGABRT

  • Ticket #18549 – Description

    initial v4  
    2424**Note**
    2525
    26 Initial investigation shows that the issue might be that the `debug_server` captures all crashing teams. It looks like when the user terminates the process through the `debug_server`, the original unhandled signal is overwritten.
     26Based on comments by waddlesplash and PulkoMandy below, the our `abort()` call in libroot calls the `debugger()` when the SIGABRT is not handled by the team. This then brings up the `debug_server` popup window that asks a user to decide what to do next (kill, debugger, core dump). A user ''can'' decide to open the Debugger and choose to continue execution. In that case, the application works as expected.