From owner-freebsd-hackers Fri Mar 2 5: 7: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id C510B37B71C for ; Fri, 2 Mar 2001 05:06:54 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f22D52P36608; Fri, 2 Mar 2001 08:05:02 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200103021305.f22D52P36608@hda.hda.com> Subject: Re: Stupid debugging pthread question In-Reply-To: from "E.B. Dreger" at "Mar 1, 2001 06:41:25 pm" To: "E.B. Dreger" Date: Fri, 2 Mar 2001 08:04:52 -0500 (EST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Date: Thu, 1 Mar 2001 12:44:39 -0500 (EST) > > From: Peter Dufault > > > > This is a stupid question, basically it's how to debug something. > > > > I have four cooperating p-threaded processes. One of them keeps getting > > a SIGSEGV with the address 0x752f422f. I'm not sure if that address is > > always the same, but with a given compile it is. The thing that's a pain > > is it is random. The four processes can run for a long time, or through > > several tests to completion, and then the > > nasty process gets that SIGSEGV. The thread that receives the SIGSEGV > > is random, the stack of the SEGV'd thread is trash, the rest of the > > threads in the offending process still have intact stacks. Arg! > > Sounds like maybe a buffer overrun or something might be trashing a return > pointer. Not sure what the exact cause is, but if that address is not an > actual address, I'd suspect that a return pointer is getting trashed. > > Any strings "/B/u" in your program? That would be stored as 0x752f422f. > > If you're using assembly with using %ebp for stack frame (yay!), then make > certain %esp isn't getting corrupted. Very good, I read those high bits off-by-one and stupidly didn't recognize the ascii: > (gdb) x/s $esp-8 > 0x826b400 : "/wd0/B/usr-src/lib/libc_r/uthread/uthread_dup2.c" > (gdb) I guess it is the "thread_fd_lock_debug/_thread_fd_unlock_debug" calls with __FILE__ that push this on the stack. I'll build a debuggable libc_r and see I see. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message