This is sources Bugzilla
Bugzilla Version 2.17.5
Bugzilla Bug 6693
  clone.S:thread_start() implementation causes an infinite _Unwind_Backtrace. Last modified: 2008-11-18 08:24
     Query page      Enter new bug
Bug#: 6693   Hardware:   Reporter: Pawel Sikora <pluto@agmk.net>
Host: Target: Build:
Product:     Add CC:
Component:   Version:   CC:
Remove selected CCs
Status: REOPENED   Priority:  
Resolution:   Severity:  
Assigned To: Ulrich Drepper <drepper@redhat.com>   Target Milestone:  
Flags: Requestee:
  backport ()
  examined ()
  testsuite ()
Summary:
Keywords:

Attachment Description Type Created Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 6693 depends on: Show dependency tree
Show dependency graph
Bug 6693 blocks:

Additional Comments:


Leave as REOPENED 
Mark bug as waiting for feedback
Mark bug as suspended
Accept bug (change status to ASSIGNED)
Resolve bug, changing resolution to
Resolve bug, mark it as duplicate of bug #
Reassign bug to
Reassign bug to owner of selected component

View Bug Activity   |   Format For Printing


Description:   Last confirmed: 0000-00-00 00:00 Opened: 2008-06-25 07:52
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?

------- Additional Comment #1 From Ulrich Drepper 2008-08-13 05:21 -------
I see no problem with the current code:

$ ./a threaded
0x804886d handler+0x1a
0x11f400 __kernel_sigreturn+0x0
0x804888b crash+0x10
0x1ff20e clone+0x5e

------- Additional Comment #2 From Pawel Sikora 2008-08-13 07:30 -------
(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?

------- Additional Comment #3 From Pawel Sikora 2008-11-18 08:24 -------
(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.

     Query page      Enter new bug
Actions: New | Query | bug # | Reports | Requests   New Account | Log In