From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32619 invoked by alias); 31 Aug 2004 17:14:45 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 32612 invoked from network); 31 Aug 2004 17:14:44 -0000 Received: from unknown (HELO granger.mail.mindspring.net) (207.69.200.148) by sourceware.org with SMTP; 31 Aug 2004 17:14:44 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1C2CDR-0001Fw-00; Tue, 31 Aug 2004 13:14:41 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id C04684B102; Tue, 31 Aug 2004 13:14:16 -0400 (EDT) Date: Tue, 31 Aug 2004 17:14:00 -0000 From: Michael Chastain To: cmarkle@sendmail.com Subject: Re: calling glibc mallinfo() from GDB after attaching to a process? Cc: gdb@sources.redhat.com Message-ID: <4134B1E6.nailHTK111G2B@mindspring.com> References: <4133DDC2.3040403@sendmail.com> <01c48f0e$Blat.v2.2.2$c9e5a100@zahav.net.il> <41340BA3.6020801@sendmail.com> <4134975D.nailH9511JUUH@mindspring.com> <4134A25C.4020700@sendmail.com> In-Reply-To: <4134A25C.4020700@sendmail.com> User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00440.txt.bz2 Chris Markle wrote: > I am getting exactly this seg fault when calling mallinfo(). Do later > versions of gdb deal better with this? No, they don't. I'm getting this seg fault with both gdb 6.2 and gdb HEAD 2004-08-30. This happens even when I use the debug version of glibc with LD_LIBRARY_PATH=/usr/lib/debug. However, this works: (gdb) print __libc_mallinfo() Looking at "readelf -w /usr/lib/libc.so.6", there is a subprogram named "__libc_mallinfo", but no subprogram named mallinfo. "mallinfo" is actually just a weak alias for "__libc_mallinfo". It looks like gdb doesn't pick up the type information for "mallinfo". That causes gdb to believe that "mallinfo" is a function that takes no arguments and returns an integer. So when gdb makes the call, it neglects to use the struct return-value convention and mallinfo dies in the assembly code that copies the struct return-value back to the caller-specified area. I have an old glibc: red hat linux 8, glibc 2.2.93-5-rh. I don't know if this is better with newer glibc's. Michael