From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26435 invoked by alias); 29 Sep 2009 04:32:03 -0000 Received: (qmail 26423 invoked by uid 22791); 29 Sep 2009 04:32:02 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Sep 2009 04:31:57 +0000 Received: from jupiter.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 5BBD41000F; Mon, 28 Sep 2009 21:31:56 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by jupiter.vmware.com (Postfix) with ESMTP id 507D0DC053; Mon, 28 Sep 2009 21:31:56 -0700 (PDT) Message-ID: <4AC18D2F.5080809@vmware.com> Date: Tue, 29 Sep 2009 04:32:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Aarthy CC: "gdb@sourceware.org" Subject: Re: reg: GDB's generate-core-file option References: <30ca7ede0909281909n40cccc62m8e3c574546f7208f@mail.gmail.com> In-Reply-To: <30ca7ede0909281909n40cccc62m8e3c574546f7208f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00319.txt.bz2 Aarthy wrote: > Hi there, > > I am currently working on a product which has many processes running > in a multi threaded fashion. Is it threads? Or forks? If it's threads, gdb should be able to save all the threads into a single corefile. Can you attach gdb to the "main" thread? > I run my product on a device which has > 200 MB of hard disk space to write the core file. It doesn't have any > swap memory as such. My requirement is that I need to collect the > snapshot of each process at a particular time. So I used > generate-core-file option after attaching each process to GDB. You didn't say how much ram your device has. Are you running a bunch of gdbs at the same time? Or are you running them one after another? generate-core-file uses a lot of ram -- if you are running many gdbs at the same time, you might be running out of memory. > The > problem is that for one process i get the following error. > > warning: Failed to write corefile contents (No space left on device). > ../../gdb/utils.c:1058: internal-error: virtual memory exhausted: > can't allocate 92123136 bytes. This is an out-of-memory error. It comes from function "nomem()" in utils.c, and results from the failure of an xmalloc() call. There is only one xmalloc() call in gcore.c, it looks like this: memhunk = xmalloc (size); This is trying to make a copy of one of the program's memory section. So your program (or this thread or fork) has a memory section that is 92,123,136 bytes long, and xmalloc can't acquire that many bytes of free memory (at least in a single hunk). > A problem internal to GDB has been detected, > further debugging may prove unreliable. > > I would like to know what could be the reason. I have about 15 > processes running. everything except this process i was able to > generate the forced core file. > This is my ulimit -a output, > > Linux(debug)# ulimit -a > core file size (blocks, -c) 73242 > data seg size (kbytes, -d) 62500 > file size (blocks, -f) unlimited > max locked memory (kbytes, -l) unlimited > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size (512 bytes, -p) 8 > stack size (kbytes, -s) unlimited > cpu time (seconds, -t) unlimited > max user processes (-u) 26624 > virtual memory (kbytes, -v) 125000 > > If i change the virtual memory size to unlimited i was able to > generate the core. Kindly let me know how exactly the > generate-core-file works. > > Regards, > Aarthy.