Summary: | devel/gdb: gdb 7.9 crashes on certain core files | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | wjenkner | ||||||||||
Component: | Individual Port(s) | Assignee: | Tijl Coosemans <tijl> | ||||||||||
Status: | Closed FIXED | ||||||||||||
Severity: | Affects Only Me | CC: | eric, jhb, luca.pizzamiglio, tijl, woodwardj | ||||||||||
Priority: | --- | Flags: | linimon:
maintainer-feedback?
(luca.pizzamiglio) |
||||||||||
Version: | Latest | ||||||||||||
Hardware: | Any | ||||||||||||
OS: | Any | ||||||||||||
Bug Depends on: | 200638 | ||||||||||||
Bug Blocks: | |||||||||||||
Attachments: |
|
Description
wjenkner
2015-05-06 16:02:21 UTC
Created attachment 156468 [details]
C source
Simpler test case.
I was unable to reproduce on HEAD, will try stable/10 later today. However, in my case I only got "New Thread" lines when parsing the core, I did not get both "New Process" and "New Thread" and I suspect that is related. Did you build gdb79 from ports or install it from a package repository? If the latter, was it from pkg.freebsd.org it from your own build? Hi, The big suspect here is the thread support and how the thread list is created when the libthr.so is loaded. There was an issue with gdb78, (solved in the revision 365578) and I guess that the fix is not able to handle the load of libthr.so when the process has already more thread (attach or core dump load of multithread programs) In other words, if you run the application inside gdb, libthr.so is processed at the beginning, when only 1 thread is running and everything is fine. gdb79 ./foo tested, it works. If you analyze the core dump or you dynamically attach gdb to a running process, gdb has inconsistent information about threads. (In reply to John Baldwin from comment #2) I compiled it from ports (using portmaster). (In reply to luca.pizzamiglio from comment #3) Running foo under gdb79 works for me as well. As the transcript above shows, gdb782 --core=foo.core ./foo does not crash but it seems to produce a duplicate backtrace of one thread, somehow. Created attachment 156667 [details]
clear_thread_list.patch
This is the workaround I've been testing. It does fix this, but it's not clear to me what the most correct fix for this is. Other libthread_db targets in gdb for Solaris and Linux just avoid attaching to core dumps entirely. This patch makes the FreeBSD thread target throw away the threads enumerated by the default core dump target and re-enumerate them using the FreeBSD target directly.
Created attachment 157220 [details]
get_current_thread before thread enumeration
(In reply to Eric Badger from comment #7) I think Luca's patch can work here, but the setting of ptid happens too late; when enumerating threads, the old thread isn't matched and so a new (duplicate) is created. Attached a possible patch that seems to handle correctly core files and the case of attaching to running processes with multiple threads. I have given Luca a similar patch (albeit a bit larger) that generally does the same thing to avoid adding a double thread. I think there are still issues with the resume method though that aren't easy to untangle. Hi to all The patch I gave to Eric is extracted from the John's one. I hopefully thought it could solve the attaching issue. I'm going to integrate the previous submitted patch, that solves this issue, in the next PR I'm preparing. A commit references this bug: Author: tijl Date: Thu Jun 4 17:08:27 UTC 2015 New revision: 388538 URL: https://svnweb.freebsd.org/changeset/ports/388538 Log: - Update to 7.9.1 - Fix crash on some core files - Fix plist PR: 200001, 200011, 200638 Submitted by: luca.pizzamiglio@gmail.com (maintainer) Changes: head/devel/gdb/Makefile head/devel/gdb/distinfo head/devel/gdb/files/fbsd-threads.c head/devel/gdb/pkg-plist |