Re: more backtraces
От | Peter Eisentraut |
---|---|
Тема | Re: more backtraces |
Дата | |
Msg-id | 737b4309-57a2-2a65-fe84-59f84d0abc4d@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: more backtraces (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On 2019-12-04 20:59, Andres Freund wrote: > On 2019-12-04 20:45:25 +0100, Peter Eisentraut wrote: >> In the previous discussions on backtrace support, some people asked for >> backtraces in more situations. Here is a patch that prints backtraces on >> SIGABRT, SIGBUS, and SIGSEGV signals. SIGABRT includes assertions and >> elog(PANIC). > > Hm. Can we really do that somewhat reliably like this? I've seen reputable programs that do all kinds of things in SIGSEGV handlers, including running user-defined programs, without taking any special precautions. So it seems possible in general. > I'd suspect that > there'll be some oddities e.g. for stack overflows if done this way. To > my knowledge it's not a good idea to intercept SIGBUS/SIGSEGV without > using a separate signal stack (cf. sigaltstack) - but using a separate > stack could also make it harder to determine a correct backtrace? Didn't know about that, but seems useful. I'll look into it. > It'd be bad if the addition of backtraces for SEGV/BUS suddenly made it > harder to attach a debugger and getting useful results. Even > disregarding the previous concerns, we'll get less useful debugger > interactions due to this, e.g. for things like null pointer derefs, > right? The backtrace and level of detail jumping around between frames I get in lldb looks the same as without this. But it might depend. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: