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/247: ../../opcodes/../ltconfig[92]: The fork function failed. There is not enough memory available.


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
 


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