Date: Fri, 2 Mar 2001 08:04:52 -0500 (EST) From: Peter Dufault <dufault@hda.hda.com> To: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> Cc: hackers@FreeBSD.ORG Subject: Re: Stupid debugging pthread question Message-ID: <200103021305.f22D52P36608@hda.hda.com> In-Reply-To: <Pine.LNX.4.20.0103011835040.29685-100000@www.everquick.net> from "E.B. Dreger" at "Mar 1, 2001 06:41:25 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > Date: Thu, 1 Mar 2001 12:44:39 -0500 (EST) > > From: Peter Dufault <dufault@hda.hda.com> > > > > 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 <dtablecount+6528>: "/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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103021305.f22D52P36608>