Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* 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