> > Date: Thu, 1 Mar 2001 12:44:39 -0500 (EST)
> > From: Peter Dufault <[EMAIL PROTECTED]>
> >
> > 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 ([EMAIL PROTECTED]) Realtime development, Machine control,
HD Associates, Inc. Fail-Safe systems, Agency approval
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
