This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/12310] pthread_exit() in main thread segfaults when statically-linked


http://sourceware.org/bugzilla/show_bug.cgi?id=12310

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
                 CC|                            |carlos at redhat dot com

--- Comment #4 from Carlos O'Donell <carlos at redhat dot com> 2013-05-23 14:02:19 UTC ---
(In reply to comment #3)
> I guess nobody expected static program working with threads but not invoking
> pthread_create() anywhere. So in real cases weak reference doesn't make
> problems
> Obvious solution could be adding reference to __nptl_nthreads in pthread_exit.c

The fact that this doesn't crash in master is sheer luck.

In the non-static case the forwarder calls exit() when you ask for
pthread_exit() and everything works correctly. In the static case you actually
call pthread_exit() and it breaks because nothing included __nptl_nthreads from
pthread_create.os and that means it has a zero value.

Static linking should work for all reasonable cases.

This case is reasonable because the main thread is a real thread and you should
be able to exit from it using pthread_exit.

We need a reference to __nptl_nthreads as you suggest. Doing so will pull in
all of pthread_exit.os into the application image, so it might grow a little in
size. I don't see that as a problem.

Please post a patch to libc-alpha@sourceware.org to fix this.

I suggest building glibc master, and testing the patch with that, and making
sure `make -k check' doesn't show any regressions.

See:
http://sourceware.org/glibc/wiki/Testing/Builds
and
http://sourceware.org/glibc/wiki/Contribution%20checklist

Your change is sufficiently minimal that it probably falls below the legally
significant barrier and doesn't require a copyright assignment. However, if you
plan to contribute more changes then we strongly recommend signing a copyright
assignment for glibc to the FSF (or whatever you want to do e.g. individual
disclaimer).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]