This is the mail archive of the gdb-patches@sources.redhat.com 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]

Re: [RFA] Don't use thread_db on corefiles


On Thu, Dec 13, 2001 at 10:57:27AM -0800, Andrew Cagney wrote:
> >This patch fixes a really frustrating internal error when you open the
> >coredump of a multithreaded application.  Depending on your kernel, either
> >the core has threads (corefile.c supports this just fine) or it doesn't. 
> >Neither way will opening libthread_db work right.

corelow.c, rather.

> Daniel, can you explain the problem?  Thread-db should work on core 
> files (or realize it is silly and not open its self).

Right now, even after the event reporting issues, thread-db will not
work with core files.  The problem is that corefile.c adds the threads
to the thread list itself - and then thread_db finds them all and adds
them again.  One or the other needs to go.  If both try to add the
threads they'll step all over each other.

My instinct was "there is support in corefile-specific code for
handling threads.  It works just fine; use it."  It's been there since
1993.  Does it have any current consumers?  I think it must, since
Kevin touched it in May and mentioned some sort of regressions.  But
Linux has never produced these before and Solaris has its own handling. 
Does AIX maybe?

Since the overwhelming response seems to be that thread-db should be
doing this, and I can't make that happen without gutting corelow and I
have no idea what platforms that use that support, I'm going to leave
this alone unless someone else has a good idea.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


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