* looking for gdb's help
@ 2019-05-14 7:35 XXX
2019-05-14 16:17 ` Simon Marchi
2019-05-17 0:37 ` Jan Kratochvil
0 siblings, 2 replies; 4+ messages in thread
From: XXX @ 2019-05-14 7:35 UTC (permalink / raw)
To: bug-gdb
hello!
i have a question about gdb debugging. while a signal cause a core dump, how can i get which thread cause the signal. the _siginfo only records the pid, not thread id. while debugging the core file, the current thread is not the thread which cause the core signal.
i am looking for your reply, thank you!
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: looking for gdb's help
2019-05-14 7:35 looking for gdb's help XXX
@ 2019-05-14 16:17 ` Simon Marchi
2019-05-14 22:04 ` Simon Marchi
2019-05-17 0:37 ` Jan Kratochvil
1 sibling, 1 reply; 4+ messages in thread
From: Simon Marchi @ 2019-05-14 16:17 UTC (permalink / raw)
To: XXX, bug-gdb, gdb
On 2019-05-14 3:26 a.m., XXX wrote:
> hello!
>
> i have a question about gdb debugging. while a signal cause a core dump, how can i get which thread cause the signal. the _siginfo only records the pid, not thread id. while debugging the core file, the current thread is not the thread which cause the core signal.
>
>
> i am looking for your reply, thank you!
>
Is this core dump created by the Linux kernel? IIRC, the Linux kernel typically
places the signalled thread first in the list of of threads, such that when I
open a core dump in GDB, thread 1 is usually the one that caused the problem.
Simon
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: looking for gdb's help
2019-05-14 16:17 ` Simon Marchi
@ 2019-05-14 22:04 ` Simon Marchi
0 siblings, 0 replies; 4+ messages in thread
From: Simon Marchi @ 2019-05-14 22:04 UTC (permalink / raw)
To: XXX, bug-gdb, gdb
On 2019-05-14 3:26 a.m., XXX wrote:
> hello!
>
> i have a question about gdb debugging. while a signal cause a core dump, how can i get which thread cause the signal. the _siginfo only records the pid, not thread id. while debugging the core file, the current thread is not the thread which cause the core signal.
>
>
> i am looking for your reply, thank you!
>
Is this core dump created by the Linux kernel? IIRC, the Linux kernel typically
places the signalled thread first in the list of of threads, such that when I
open a core dump in GDB, thread 1 is usually the one that caused the problem.
Simon
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: looking for gdb's help
2019-05-14 7:35 looking for gdb's help XXX
2019-05-14 16:17 ` Simon Marchi
@ 2019-05-17 0:37 ` Jan Kratochvil
1 sibling, 0 replies; 4+ messages in thread
From: Jan Kratochvil @ 2019-05-17 0:37 UTC (permalink / raw)
To: XXX; +Cc: gdb
On Tue, 14 May 2019 09:26:56 +0200, XXX wrote:
> i have a question about gdb debugging. while a signal cause a core dump, how
> can i get which thread cause the signal.
$ eu-readelf corefile # eu-readelf is from elfutils package
Owner Data size Type
CORE 336 PRSTATUS
info.si_signo: 11, info.si_code: 0, info.si_errno: 0, cursig: 11
sigpend: <>
sighold: <>
pid: 2700200, ppid: 2700198, pgrp: 2700198, sid: 2652754
^^^^^^^ = crashed thread TID
...
CORE 136 PRPSINFO
state: 2, sname: D, zomb: 0, nice: 0, flag: 0x0000000040404404
uid: 1001, gid: 1001, pid: 2700199, ppid: 2700198, pgrp: 2700198
^^^^^^^ = crashed process PID
Jan
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-05-15 14:28 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-14 7:35 looking for gdb's help XXX
2019-05-14 16:17 ` Simon Marchi
2019-05-14 22:04 ` Simon Marchi
2019-05-17 0:37 ` Jan Kratochvil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox