Ref: https://sourceware.org/ml/libc-alpha/2014-11/msg00534.html Consider the statically-linked libpthread case, where the main executable is where the libpthread symbols are actually found. Some of the libpthread symbols thread_db wants to looks up, although static, have names that aren't in the implementation namespace. As such, if the statically-linked program happens to have other symbols with the same name, GDB might well find and return those to nptl_db instead. For example, it should be perfectly legitimate for a program to define a symbol called "stack_used", but that ends up confusing nptl_db/gdb, because that's one of the static libpthread symbols nptl_db looks up: /* List of the stacks in use. */ static LIST_HEAD (stack_used); And that's exactly what happened in: [Bug 9635 - Cannot find new threads: generic error] https://sourceware.org/bugzilla/show_bug.cgi?id=9635
Actually looks like "stack_used" may be the only one with the problem: $ grep -rn DB_GET_SYMBOL -rn nptl_db/td_ta_thr_iter.c:157: err = DB_GET_SYMBOL (list, ta, __stack_user); nptl_db/td_ta_thr_iter.c:164: err = DB_GET_SYMBOL (list, ta, stack_used); nptl_db/td_ta_tsd_iter.c:53: err = DB_GET_SYMBOL (addr, ta, __pthread_keys); nptl_db/td_ta_event_addr.c:40: err = DB_GET_SYMBOL (taddr, ta, __nptl_create_event); nptl_db/td_ta_event_addr.c:44: err = DB_GET_SYMBOL (taddr, ta, __nptl_death_event); nptl_db/td_thr_validate.c:65: err = DB_GET_SYMBOL (list, th->th_ta_p, __stack_user); nptl_db/td_thr_validate.c:73: err = DB_GET_SYMBOL (list, th->th_ta_p, stack_used); nptl_db/td_ta_map_lwp2thr.c:190: td_err_e err = DB_GET_SYMBOL (list, ta, __stack_user); nptl_db/td_ta_set_event.c:41: err = DB_GET_SYMBOL (eventmask, ta, __nptl_threads_events); nptl_db/thread_dbP.h:150:#define DB_GET_SYMBOL(var, ta, name) \ nptl_db/td_thr_event_getmsg.c:71: err = DB_GET_SYMBOL (prevp, th->th_ta_p, __nptl_last_event); nptl_db/td_ta_clear_event.c:41: err = DB_GET_SYMBOL (eventmask, ta, __nptl_threads_events); Though renaming __stack_user to __nptl_stack_user too might be good, in case other parts of the implementation (e.g., libgcc) might end up defining their own unrelated static symbols with that name too.