This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: gdb/247: ../../opcodes/../ltconfig[92]: The fork function failed. There is not enough memory available.
- From: "Scott Zetlan" <scottzetlan at aol dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 22 Mar 2002 18:38:02 -0000
- Subject: Re: gdb/247: ../../opcodes/../ltconfig[92]: The fork function failed. There is not enough memory available.
- Reply-to: "Scott Zetlan" <scottzetlan at aol dot com>
The following reply was made to PR gdb/247; it has been noted by GNATS.
From: "Scott Zetlan" <scottzetlan@aol.com>
To: <dave.anglin@nrc.ca>, <ac131313@cygnus.com>
Cc: <nobody@sources.redhat.com>, <gdb-gnats@sources.redhat.com>,
<gdb-prs@sources.redhat.com>
Subject: Re: gdb/247: ../../opcodes/../ltconfig[92]: The fork function failed. There is not enough memory available.
Date: Fri, 22 Mar 2002 13:36:14 -0500
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&databas
e=gdb&pr=247
I was wondering if either of you could elaborate on the fix for the ttrace
wait problem? I assume I need to add a line like:
#define vfork fork
to one of the files, but I didn't know if a particular one is required
(intl/config.h? gdb/defs.h?).
I added it to gdb/defs.h, which "fixed" the problem, but now I'm getting a
core dump in gdb/thread.c:125. It seems that gdb/infttrace.c:3126 calls
add_thread(pid), where pid is an integer -- the process ID of the child
(i.e., the thing I'm trying to debug). The add_thread() function is really
expecting something of type ptid_t, which is a structure of pid, lwp, and
tid.
Strangely, when I start gdb and attach to a running process, everything is
ok -- but maybe it's using a different path to get to add_thread().
I'm building 5.1.1 for hppa2.0w-hp-hpux11.00.
Thanks in advance,
Scott