This is the mail archive of the gdb-prs@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: gdb/366: HPUX hangs during fork


The following reply was made to PR gdb/366; it has been noted by GNATS.

From: law@redhat.com
To: Andrew Cagney <ac131313@cygnus.com>
Cc: ezannoni@redhat.com, ac131313@redhat.com, gdb-gnats@sources.redhat.com
Subject: Re: gdb/366: HPUX hangs during fork 
Date: Mon, 08 Apr 2002 09:47:17 -0600

  In message <3CB0B680.1000704@cygnus.com>, Andrew Cagney writes:
  > Here's the problem: gdb starts just fine, but then when I attempt to run a
  > program, it hangs.  I've gotten a core dump from gdb, which I traced with
  > gdb, and found that it's hanging at add_thread (thread.c) called from
  > child_acknowledge_created_inferior (infttrace.c).
 This sounds like the problem I was looking at many months ago -- basically
 anytime GDB started an inferior program it would hang.  I originally thought
 the problem was the fork/vfork following code in infttrace.c, but that theory
 was disproven when the same hanging behavior was found on hpux10.20 (which
 does not use infttrace at all).
 
 We've been working around with something like -Dvfork=fork when compiling
 GDB, but that's clearly not a long term solution.
 
 
  > It appears that child...inferior () accepts an int (int pid) as an argument,
  > and then passes that int to add_thread (line 3126).  The add_thread()
  > function actually takes a ptid_t (typdef'd in def.h as a struct ptid) as an
  > argument.  My core dump shows that gdb is attempting to access memory at
  > 0x3d4, which evaluates to 980, or the pid of the child process.
 So what happens instead of passing the pid to add_thread you instead pass
 pid_to_ptid(pid))?
 
 jeff
 
 


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