This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug threads/21324] gdb hangs when 'thread apply all bt full' is used


https://sourceware.org/bugzilla/show_bug.cgi?id=21324

--- Comment #11 from Pedro Alves <palves at redhat dot com> ---
Is that a pristine upstream GDB, or an ubuntu GDB?  The reason I ask is that
ubuntu's gdb may have local patches that who knows, might cause this.  It'd be
nice to test with current upstream master.  That'd also let us know whether the
issue might be fixed already.

Looking at the backtrace, we're in inline_frame_sniffer ->
frame_unwind_register -> dwarf2_tailcall_sniffer_first, and then end up in the
dwarf reader.

Both the inline and tailcall sniffers rely on accurate debug/unwind info.
I can imagine cycles appearing with e.g., bad unwind info.
I'd suspect something odd along those lines.

Also, seeing the two sniffers in the same backtrace is suspicious.

I think the next step would be to determine where exactly is the cycle.  I.e.,
once you get a hung gdb, attach to it, and step through the code until you
figure out what's the infinite that never breaks.

I'd disable the frame filters and whatever other scripts gdb may be loading, to
confirm that the problem isn't being triggered by something they're doing.  If
that "fixes" the problem, them we have a better idea where to look next.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]