This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: gdb/366: HPUX hangs during fork
- From: law at redhat dot com
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 8 Apr 2002 15:48:04 -0000
- Subject: Re: gdb/366: HPUX hangs during fork
- Reply-to: law at redhat dot com
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