Need help for system calls

[Partha Chatterjee]

Hi Daniel,

I am sending a piece of code + gdb trace as an attachment.
(2 attachments, .c (y.c) and stack trace (stk-trace.txt))

Please check the stack contents of func4() function (in gdb) while we
are still in the nanosleep() context.

The current version of glibc I am using is 2.3.2-11.9.

In the meantime I will try with latest glibc and gdb.


Thanks,
Partha
x3025


-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@false.org] 
Sent: Thursday, January 05, 2006 8:27 PM
To: Partha Chatterjee; libc-alpha@gnu.org
Subject: Re: Need help for system calls


On Thu, Jan 05, 2006 at 09:56:01AM -0500, Daniel Jacobowitz wrote:
> On Thu, Jan 05, 2006 at 07:33:52PM +0530, Partha Chatterjee wrote:
> > Hello,
> > 
> > I will try to explain my problem through some stack-traceback 
> > examples
> > 
> > The code is something as follows
> > main() ----> calls func1() ----> calls func2() ----> calls 
> > nanosleep()
> > 
> > When I enter func2() from func1() the arguments passed to func2 + 
> > (its local stack) is proper. Once the control enters nanosleep() and

> > if at that point (i.e when the process
> > is still in the nanosleep() context) I send a signal to the process,
the
> > following thing is 
> > observed (same is observed in case I attach gdb to the process while
the
> > context is
> > still in nanosleep()).
> > 
> > The stack of func2() gets overloaded with the contents of func1() 
> > and there is no way to check what were the contents of func2()'s 
> > stack. (It is always the previous function's (in
> > the call-stack) stack that gets overloaded).
> 
> What you've written doesn't make sense.  What I suspect you mean is 
> that GDB is failing to show you the proper backtrace, right?  If so, 
> this is generally inadequate debugging information in your C library.

And in case this wasn't clear: current versions of glibc + gdb shouldn't
have this problem.

-- 
Daniel Jacobowitz
CodeSourcery
-------------- next part --------------
A non-text attachment was scrubbed...
Name: y.c
Type: application/octet-stream
Size: 1740 bytes
Desc: y.c
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20060105/98938e64/attachment.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stk-trace.txt
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20060105/98938e64/attachment.txt>