Bug 6693 - clone.S:thread_start() implementation causes an infinite _Unwind_Backtrace.
Summary: clone.S:thread_start() implementation causes an infinite _Unwind_Backtrace.
Status: RESOLVED WORKSFORME
Alias: None
Product: glibc
Classification: Unclassified
Component: nptl (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-25 07:52 UTC by Pawel Sikora
Modified: 2014-07-04 06:33 UTC (History)
1 user (show)

See Also:
Host:
Target: x86_64-gnu-linux
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pawel Sikora 2008-06-25 07:52:10 UTC
this is a forward from gcc bugzilla:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36568
afaics the glibc-2.8 is affected and there's
a patch provided in debian/ubuntu distro.
could you please verify and commit linked patch?
Comment 1 Ulrich Drepper 2008-08-13 05:21:47 UTC
I see no problem with the current code:

$ ./a threaded
0x804886d handler+0x1a
0x11f400 __kernel_sigreturn+0x0
0x804888b crash+0x10
0x1ff20e clone+0x5e
Comment 2 Pawel Sikora 2008-08-13 07:30:36 UTC
(In reply to comment #1)
> I see no problem with the current code:
>
> $ ./a threaded
> 0x804886d handler+0x1a
> 0x11f400 __kernel_sigreturn+0x0
> 0x804888b crash+0x10
> 0x1ff20e clone+0x5e

which kernel/glibc/gcc/distribution you are using?
Comment 3 Pawel Sikora 2008-11-18 08:24:12 UTC
(In reply to comment #1)
> I see no problem with the current code:
> 
> $ ./a threaded
> 0x804886d handler+0x1a
> 0x11f400 __kernel_sigreturn+0x0
> 0x804888b crash+0x10
> 0x1ff20e clone+0x5e

did you test it on the x86_64 architecture?
i'm asking because your logs shows 32-bits addresses
and the problem exist only on x86_64.
Comment 4 Andreas Schwab 2010-11-19 16:59:51 UTC
Not reproducible.