libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [libunwind] 6 regression tests on x86 failing


From: Kuanbekov, Artyom
Subject: RE: [libunwind] 6 regression tests on x86 failing
Date: Tue, 25 Oct 2005 10:03:40 +0400

Yes you are right. The problem with __clone is that new thread starts
right after int 80 instruction, however .eh_frame describes WHOLE
__clone function. As the result unw_step() tries to look before __clone.


The workaround for this may be check of stack. If unw_init_local can
accept current thread stack then unw_step() will check whether it tries
to look outside the stack and do not step further.

Additional stack pointer parameter in unw_init_local() will also allow
developers to limit stack to unwind. This will increase robustness of
the library.

What do you think?

Best regards,
Artyom.

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of
David Mosberger-Tang
Sent: Tuesday, October 25, 2005 02:31
To: Kuanbekov, Artyom
Cc: address@hidden
Subject: Re: [libunwind] 6 regression tests on x86 failing

x86 is pretty hopeless, because the unwind info in libc is incomplete.
 Check the libc bugzilla for a bug report I submitted a while ago
(sorry, I don't have the number handy).  x86-64 is in better shape
there --- at least they _try_ to provide proper unwind info in libc.

Thanks,

  --david

On 10/24/05, Kuanbekov, Artyom <address@hidden> wrote:
>
>
>
> I am also getting segmentation fault when back tracing from pthread
routine.
>
>
>
> I modified Gtest-concurent slightly to print function name as well.
The last
> function which was successfully retrieved with unw_step() was __clone.
Next
> call to unw_step() causes segmentation fault on x86. It seems like
__clone
> stack frame is tracked differently comparing to _start function which
is
> called when program starts. Moreover I put implicit handler(0) call
into
> worker() routine instead of pthread_kill() and got the same result. So
the
> problem not in signal handler.
>
>
>
> I tried all 0.98.x versions. Which version of libunwind does not have
such
> problem?
>
>
>
> Thanks,
>
> Artyom.
>
>
> _______________________________________________
> libunwind mailing list
> address@hidden
> http://www.hpl.hp.com/hosted/linux/mail-archives/libunwind/
>
>


--
Mosberger Consulting LLC, voice/fax: 510-744-9372,
http://www.mosberger-consulting.com/
35706 Runckel Lane, Fremont, CA 94536


reply via email to

[Prev in Thread] Current Thread [Next in Thread]