Re: Stupid debugging pthread question

2001-03-02 Thread Peter Dufault
> > (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. Well, of course with the

Re: Stupid debugging pthread question

2001-03-02 Thread E.B. Dreger
> Date: Fri, 2 Mar 2001 08:04:52 -0500 (EST) > From: Peter Dufault <[EMAIL PROTECTED]> > > 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. (I mea

Re: Stupid debugging pthread question

2001-03-02 Thread Peter Dufault
> > 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 no

Re: Stupid debugging pthread question

2001-03-01 Thread E.B. Dreger
> 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

Re: Stupid debugging pthread question

2001-03-01 Thread Peter Pentchev
On Thu, Mar 01, 2001 at 12:44:39PM -0500, Peter Dufault wrote: > 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 sa

Stupid debugging pthread question

2001-03-01 Thread 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 ran