From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12486 invoked by alias); 14 Jun 2005 20:52:30 -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 12258 invoked by uid 22791); 14 Jun 2005 20:52:15 -0000 Received: from camomile.cloud9.net (HELO camomile.cloud9.net) (168.100.1.3) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 14 Jun 2005 20:52:15 +0000 Received: from camomile.cloud9.net (localhost.cloud9.net [127.0.0.1]) by camomile.cloud9.net (Postfix) with SMTP id B29885523 for ; Tue, 14 Jun 2005 16:52:13 -0400 (EDT) Received: from keyslapper.net (250-119.customer.cloud9.net [168.100.250.119]) by camomile.cloud9.net (Postfix) with ESMTP id 4C49D54EE for ; Tue, 14 Jun 2005 16:52:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by keyslapper.net (Postfix) with ESMTP id DACC7114FD for ; Tue, 14 Jun 2005 16:52:12 -0400 (EDT) Received: from keyslapper.net ([127.0.0.1]) by localhost (keyslapper.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41806-06 for ; Tue, 14 Jun 2005 16:52:12 -0400 (EDT) Received: by keyslapper.net (Postfix, from userid 1001) id A178C114D2; Tue, 14 Jun 2005 16:52:12 -0400 (EDT) Date: Tue, 14 Jun 2005 20:52:00 -0000 From: Louis LeBlanc To: gdb@sources.redhat.com Subject: Re: stack corruption? Message-ID: <20050614205212.GK62467@keyslapper.net> Reply-To: gdb@sources.redhat.com Mail-Followup-To: gdb@sources.redhat.com References: <20050614014520.GG24814@keyslapper.net> <20050614020138.GA19453@nevyn.them.org> <20050614033256.GB48802@keyslapper.net> <10DBEAA7-48B2-4298-A8CC-58A138415516@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <10DBEAA7-48B2-4298-A8CC-58A138415516@apple.com> User-Agent: Mutt/1.5.9i Content-Transfer-Encoding: quoted-printable X-AntiVirus: Checked by Vexira Antivirus v1.5 X-SW-Source: 2005-06/txt/msg00143.txt.bz2 On 06/14/05 01:35 PM, Jason Molenda sat at the `puter and typed: >=20 > On Jun 13, 2005, at 8:32 PM, Louis LeBlanc wrote: >=20 > > Stack corruption shows up anytime I open the program in gdb. I get an > > occasional core dump (SEGV and BUS) from my program, but when I can > > make heads or tails of it, it appears to be deep in a host lookup > > (system libs, Solaris 9) or Oracle 8.1.7 database calls (which could > > also be a host lookup). >=20 >=20 > Louis, I think you're going to need to be a lot more specific.=20=20=20 > You're using gdb on Solaris 9 with a SPARC CPU? What version of=20=20 > gdb? Your paragraph above sounds like there's a bug in your program=20=20 > causing it to crash, and you cannot understand the stack backtrace --=20= =20 > are you asking for help in using gdb to find your bug, or are you=20=20 > saying that gdb is not behaving properly? >=20 > If it's the latter, some example output of the problem would do=20=20 > wonders to clear things up. Sorry for being too general. I am on a SPARC, running Solaris 8 and 9 on different machines. Whether there's a bug in my code, well, I'm sure there are minor bugs, but I'm not convinced yet that there's a serious one. This process runs at high network volumes for days and weeks at a time without problem, then suddenly it dumps. When I try to examine the core, I get stack corruption messages. Basically, I'm not entirely sure. The codebase in question has never had this problem in the past, but now (with a newer version of gdb, and after much work on my code) I always get the corrupt stack notice when I open the process in gdb. The gdb version I am using is: $ gdb -v GNU gdb 6.3.0.20050516-cvs I have been planning to get a later snapshot, but haven't gotten around to it yet. BTW, I've seen problems in several applications while performing network lookups, not just my code, and not just C programs. I got a couple created by Perl scripts a couple weeks ago and they were also in the middle of network lookups. This makes me skeptical of the system libs, not my code and not gcc. The real problem is that gdb tells me nothing useful in these cases, unless the corrupt stack message is a real issue with my code. BTW, I have always used the standard pstack utility on all cores I've had to examine on Solaris - they don't always match up directly with the gdb backtrace, but they're usually close. Thread numbers and LWP ids are sometimes way off too. Lou --=20 Louis LeBlanc dev@keyslapper.net Fully Funded Hobbyist, KeySlapper Extrordinaire :=FE http://www.keyslapper.net =D4=BF=D4=AC Key fingerprint =3D C5E7 4762 F071 CE3B ED51 4FB8 AF85 A2FE 80C8 D9A2 Facts are stubborn, but statistics are more pliable.