Summary: | nptl_db: stale thread create/death events if debugger detaches | ||
---|---|---|---|
Product: | glibc | Reporter: | Pedro Alves <pedro> |
Component: | nptl | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | NEW --- | ||
Severity: | normal | CC: | drepper.fsp |
Priority: | P2 | Flags: | fweimer:
security-
|
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Attachments: | WIP fix |
Description
Pedro Alves
2014-12-12 17:28:20 UTC
Created attachment 8010 [details]
WIP fix
WIP fix. The main idea is that whenever a __nptl_*_event event function is called, the debugger is expected to consume the event (see nptl_db/td_ta_event_getmsg.c). If the event wasn't consumed, then it must be the debugger is either gone, or misbehaved. The death event is to reason about -- clearly we shouldn't hang on the event forever, as the thread is about to be wiped out. So right after calling the event function, we remove the thread from the event queue. The complication is that a new debugger may manage to reattach just while we're doing that, and the code must be written in a way that works without any locking/synchronization between the debugger and the inferior.
I'm not going to be working on this fix further, at least for now. GDB doesn't really need to be using libthread_db's thread creation/destruction events nowadays when the kernel supports PTRACE_EVENT_CLONE, which it has for a long while. I'll work on that instead. |