Modify

Ticket #5013 (closed Bugs: fixed)

Opened 3 years ago

Last modified 23 months ago

documentation: boost::thread: pthreas_exit causes terminate()

Reported by: Slava <Viatcheslav.Sysoltsev@…> Owned by: viboes
Milestone: Boost 1.50.0 Component: thread
Version: Boost 1.36.0 Severity: Problem
Keywords: doc native threads Cc: viboes

Description

boost::thread before svn revision 49969 causes the terminate() to be called if the child thread exits with pthread_exit() on linux.

See the proof test case (environment: Boost 1.36, gcc 4.3.2, openSUSE 11.1, x86_64 architecture.):

#include <boost/thread.hpp>

void tf()
{
    pthread_exit(NULL);
}


int main()
{
    boost::thread t(tf);
    t.join();
    return  0;
}

> g++ -g -O0 test2.cpp -lboost_thread && gdb a.outGNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/vsysolts/test/boost_thread/a.out...done.
(gdb) r
Starting program: /home/vsysolts/test/boost_thread/a.out 
[Thread debugging using libthread_db enabled]
[New Thread 0x7ffff6cd5950 (LWP 14284)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff6cd5950 (LWP 14284)]
0x00007ffff798a565 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib64/libstdc++.so.6
(gdb) bt
#0  0x00007ffff798a565 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib64/libstdc++.so.6
#1  0x00007ffff7988a46 in ?? () from /usr/lib64/libstdc++.so.6
#2  0x00007ffff7988a73 in std::terminate() () from /usr/lib64/libstdc++.so.6
#3  0x00007ffff7bd898a in thread_proxy () from /usr/lib64/libboost_thread.so.1.36.0
#4  0x00007ffff6cdd070 in start_thread () from /lib64/libpthread.so.0
#5  0x00007ffff71ce11d in clone () from /lib64/libc.so.6
#6  0x0000000000000000 in ?? ()

pthread_exit implementation uses the special forced_unwind exception to unwind the stack, which is (wrongly) caught in boost:thread code and used as a reason to call terminate(). The misbehaviour is commented out since svn rev 49969. Due to the fact the pthread_exit is quite legal possibility to end the single thread, the fact of incompatibility with former boost:thread implementation should be mentionen in the documentation of the boost releases up to veriosn 1.37 (presumably). I would add the mention about pthread_exit in the files doc/html/thread/thread_management.html, chapter "Exceptions in thread functions".

Attachments

Change History

comment:1 Changed 3 years ago by steven_watanabe

  • Owner changed from matias to anthonyw
  • Component changed from Documentation to thread

comment:2 Changed 2 years ago by viboes

  • Keywords doc native threads added

comment:3 Changed 2 years ago by viboes

  • Cc viboes added
  • Owner changed from anthonyw to viboes
  • Status changed from new to assigned
  • Milestone changed from To Be Determined to Boost 1.49.0

For the time been I propose to add this section

pthread_exit POSIX limitation

pthread_exit in glibc/NPTL causes a "forced unwind" that is almost like a C++ exception, but not quite. On Mac OS X, for example, pthread_exit unwinds without calling C++ destructors.

This behavior is incompatible with the current Boost.Thread design, so the use of this function in a POSIX thread result in undefined behavior of any Boost.Thread function.

Committed in trunk at #75904.

comment:4 Changed 23 months ago by viboes

  • Status changed from assigned to closed
  • Resolution set to fixed
  • Milestone changed from Boost 1.49.0 to Boost 1.50.0

Committed in release branch at [78543]

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.