Thread crash in destructor
Hi all, I had been using an old boost system and boost thread lib for a couple of years without upgrading it since approx. 2014. With this old lib the following (simplified) code works fine on OSX: #include "test.h" test::test() { boost::thread::attributes attrs; /// START TRACEROUTE THREAD #if defined(BOOST_THREAD_PLATFORM_WIN32) res = SetThreadPriority(attrs.native_handle(), THREAD_PRIORITY_NORMAL); #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) pthread_attr_setschedpolicy(attrs.native_handle(), SCHED_FIFO); #endif tracerouteThread = boost::thread( attrs, boost::bind(&test::performTraceroute, this)); } void test::performTraceroute() { cout << "START TRACEROUTE" << endl; string exec = ""; cout << "DO FURTHER STUFF BUT THIS IS JUST A DEMO ..." << endl; cout << "THREAD OVER" << endl; } Using the current boost 1_77 still does execute the thread but then it crashes within the destructor. Adding tracerouteThread.join() or .detach() after launching the thread does not help either. Can anyone help how to resolve this issue ? Thanks a lot in advance, best Alex -- http://www.carot.de Email : Alexander@Carot.de Tel.: +49 (0)177 5719797
The behavior changed in BOOST_THREAD_VERSION 3 (which is default in boost 1.77). Are you sure detach() and join() do not help? Can you provide a call stack? On 10/7/21 06:09, Alexander Carôt via Boost-users wrote:
Hi all,
I had been using an old boost system and boost thread lib for a couple of years without upgrading it since approx. 2014. With this old lib the following (simplified) code works fine on OSX:
#include "test.h"
test::test() { boost::thread::attributes attrs;
/// START TRACEROUTE THREAD #if defined(BOOST_THREAD_PLATFORM_WIN32) res = SetThreadPriority(attrs.native_handle(), THREAD_PRIORITY_NORMAL); #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) pthread_attr_setschedpolicy(attrs.native_handle(), SCHED_FIFO); #endif tracerouteThread = boost::thread( attrs, boost::bind(&test::performTraceroute, this)); }
void test::performTraceroute() { cout << "START TRACEROUTE" << endl;
string exec = ""; cout << "DO FURTHER STUFF BUT THIS IS JUST A DEMO ..." << endl; cout << "THREAD OVER" << endl; }
Using the current boost 1_77 still does execute the thread but then it crashes within the destructor. Adding
tracerouteThread.join() or .detach() after launching the thread does not help either.
Can anyone help how to resolve this issue ?
Thanks a lot in advance, best
Alex
-- http://www.carot.de Email : Alexander@Carot.de Tel.: +49 (0)177 5719797
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
Hej Juan, thanks for the quick response !
Are you sure detach() and join() do not help?
Yes, I checked it several times. I put either tracerouteThread.join() or tracerouteThread.dispatch() right after launching it but it resultet in the same effect. Please find the OSX-report here – thread 4 is the one that crashes (just in case: My app uses Qt): Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff69658dfa mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff69659170 mach_msg + 60 2 com.apple.CoreServices.CarbonCore 0x00007fff30844d1d _scsclient_CacheableGetDataWithStringKey + 207 3 com.apple.CoreServices.CarbonCore 0x00007fff30844c44 RemoteCacheable::GetWithStringKey(unsigned int, char const*, unsigned long*, unsigned int*) + 70 4 com.apple.CoreServices.CarbonCore 0x00007fff30844ae6 _CSGetNamedData + 98 5 com.apple.AppKit 0x00007fff2c6b5e19 _NSPersistentUIGetShmem + 115 6 com.apple.AppKit 0x00007fff2c6b59c0 _NSPersistentUIEstablishTalagentCommunication + 113 7 com.apple.AppKit 0x00007fff2c6b4d91 -[NSApplication finishLaunching] + 66 8 com.apple.AppKit 0x00007fff2c6b4a20 -[NSApplication run] + 244 9 libqcocoa.dylib 0x000000010fcf2f18 QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 2120 (qcocoaeventdispatcher.mm:431) 10 org.qt-project.QtCore 0x000000010f637d36 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 470 (qeventloop.cpp:232) 11 org.qt-project.QtCore 0x000000010f62f092 QCoreApplication::exec() + 130 12 com.yourcompany.soundjack 0x000000010dfb6b41 main + 2817 13 libdyld.dylib 0x00007fff69517cc9 start + 1 Thread 1: 0 libsystem_pthread.dylib 0x00007fff69717b68 start_wqthread + 0 Thread 2: 0 libsystem_pthread.dylib 0x00007fff69717b68 start_wqthread + 0 Thread 3: 0 libsystem_pthread.dylib 0x00007fff69717b68 start_wqthread + 0 Thread 4 Crashed: 0 libboost_thread.dylib 0x000000010e4a4570 tls_destructor + 96 1 libboost_thread.dylib 0x000000010e4a5784 thread_proxy + 148 2 libsystem_pthread.dylib 0x00007fff6971c109 _pthread_start + 148 3 libsystem_pthread.dylib 0x00007fff69717b8b thread_start + 15 Thread 4 crashed with X86 Thread State (64-bit): rax: 0x00000010018da37d rbx: 0x00000010018da37d rcx: 0x0000000000000008 rdx: 0x00007fef2dd18320 rdi: 0x00007fef2dd18180 rsi: 0x00000000000120a8 rbp: 0x000070000346ff70 rsp: 0x000070000346ff30 r8: 0x00000000000130a8 r9: 0x0000000000000000 r10: 0x00007fff8fc0dbf8 r11: 0x00007fff8fc0dbf0 r12: 0x00007fef2dd18180 r13: 0x0000000000000000 r14: 0x00007fef2dd18328 r15: 0x0000000000000000 rip: 0x000000010e4a4570 rfl: 0x0000000000010206 cr2: 0x00000010018da385 -- http://www.carot.de Email : Alexander@Carot.de Tel.: +49 (0)177 5719797
Gesendet: Donnerstag, 07. Oktober 2021 um 21:06 Uhr Von: "Juan Ramírez" <jramirez.uy@gmail.com> An: boost-users@lists.boost.org Cc: "Alexander Carôt" <alexander_carot@gmx.net> Betreff: Re: [Boost-users] Thread crash in destructor
The behavior changed in BOOST_THREAD_VERSION 3 (which is default in boost 1.77). Are you sure detach() and join() do not help?
Can you provide a call stack?
On 10/7/21 06:09, Alexander Carôt via Boost-users wrote:
Hi all,
I had been using an old boost system and boost thread lib for a couple of years without upgrading it since approx. 2014. With this old lib the following (simplified) code works fine on OSX:
#include "test.h"
test::test() { boost::thread::attributes attrs;
/// START TRACEROUTE THREAD #if defined(BOOST_THREAD_PLATFORM_WIN32) res = SetThreadPriority(attrs.native_handle(), THREAD_PRIORITY_NORMAL); #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) pthread_attr_setschedpolicy(attrs.native_handle(), SCHED_FIFO); #endif tracerouteThread = boost::thread( attrs, boost::bind(&test::performTraceroute, this)); }
void test::performTraceroute() { cout << "START TRACEROUTE" << endl;
string exec = ""; cout << "DO FURTHER STUFF BUT THIS IS JUST A DEMO ..." << endl; cout << "THREAD OVER" << endl; }
Using the current boost 1_77 still does execute the thread but then it crashes within the destructor. Adding
tracerouteThread.join() or .detach() after launching the thread does not help either.
Can anyone help how to resolve this issue ?
Thanks a lot in advance, best
Alex
-- http://www.carot.de Email : Alexander@Carot.de Tel.: +49 (0)177 5719797
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
On 7/10/2021 22:09, Alexander Carôt wrote:
I had been using an old boost system and boost thread lib for a couple of years without upgrading it since approx. 2014. With this old lib the following (simplified) code works fine on OSX:
#include "test.h"
test::test() { boost::thread::attributes attrs;
/// START TRACEROUTE THREAD #if defined(BOOST_THREAD_PLATFORM_WIN32) res = SetThreadPriority(attrs.native_handle(), THREAD_PRIORITY_NORMAL); #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) pthread_attr_setschedpolicy(attrs.native_handle(), SCHED_FIFO); #endif tracerouteThread = boost::thread( attrs, boost::bind(&test::performTraceroute, this));
For Win32, you can't call SetThreadPriority like that -- at best, that's doing nothing, at worst, you're changing the priority of some random thread but never the one you intend. (The attrs.native_handle is not a thread handle.) You must wait until the thread is actually started before you can set its priority. Usually the best place to set it is from the thread's method itself.
For Win32, you can't call SetThreadPriority like that -- at best, that's doing nothing, at worst, you're changing the priority of some random thread but never the one you intend. (The attrs.native_handle is not a thread handle.)
Allright, thanks for this additional info thought which comes on top of the crashing issue on OSX. Once we have sorted out why it crashes in the destructor I'd like to get back to this.
You must wait until the thread is actually started before you can set its priority. Usually the best place to set it is from the thread's method itself.
Is this related to any platform or just WIN32 as you mention above ? In other words: Is my approach of setting the priority fine for OSX and Linux or should it be changed as well ? Best Alex -- http://www.carot.de Email : Alexander@Carot.de Tel.: +49 (0)177 5719797
Gesendet: Freitag, 08. Oktober 2021 um 00:40 Uhr Von: "Gavin Lambert via Boost-users" <boost-users@lists.boost.org> An: boost-users@lists.boost.org Cc: "Gavin Lambert" <boost@mirality.co.nz> Betreff: Re: [Boost-users] Thread crash in destructor
On 7/10/2021 22:09, Alexander Carôt wrote:
I had been using an old boost system and boost thread lib for a couple of years without upgrading it since approx. 2014. With this old lib the following (simplified) code works fine on OSX:
#include "test.h"
test::test() { boost::thread::attributes attrs;
/// START TRACEROUTE THREAD #if defined(BOOST_THREAD_PLATFORM_WIN32) res = SetThreadPriority(attrs.native_handle(), THREAD_PRIORITY_NORMAL); #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) pthread_attr_setschedpolicy(attrs.native_handle(), SCHED_FIFO); #endif tracerouteThread = boost::thread( attrs, boost::bind(&test::performTraceroute, this));
For Win32, you can't call SetThreadPriority like that -- at best, that's doing nothing, at worst, you're changing the priority of some random thread but never the one you intend. (The attrs.native_handle is not a thread handle.)
You must wait until the thread is actually started before you can set its priority. Usually the best place to set it is from the thread's method itself. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
On Fri, Oct 8, 2021 at 1:01 AM Alexander Carôt via Boost-users < boost-users@lists.boost.org> wrote:
You must wait until the thread is actually started before you can set its priority. Usually the best place to set it is from the thread's method itself.
Is this related to any platform or just WIN32 as you mention above ? In other words: Is my approach of setting the priority fine for OSX and Linux or should it be changed as well ?
You can't set traits on a thread that doesn't exist, regardless of platform, Posix APIs offer a way to set up attributes to be applied to a new thread at thread creation. At first, that's what I thought you were doing, but when I look at your code, I'm not sure what you're doing. I don't see a definitely for `attrs` anywhere in the snippet, but I'm guessing that `attrs.native_handle()` is supposed to return a `pthread_t` ? If so, then your call to pthread_attr_setschedpolicy() doesn't match its prototype--which takes a pthread_attr_t* as first arg.
#elif defined(BOOST_THREAD_PLATFORM_PTHREAD) pthread_attr_setschedpolicy(attrs.native_handle(),
SCHED_FIFO);
#endif tracerouteThread = boost::thread( attrs, boost::bind(&test::performTraceroute, this));
For Win32, you can't call SetThreadPriority like that -- at best, that's doing nothing, at worst, you're changing the priority of some random thread but never the one you intend. (The attrs.native_handle is not a thread handle.)
You must wait until the thread is actually started before you can set its priority. Usually the best place to set it is from the thread's method itself.
On linux, sometimes the only way you can actually set priority on a thread is to set the attributes prior to thread creation and create the thread that way. This would be the case if you're using something like `isolcpus` on your kernel, and the thread doing the creating is running on one of the isolcpus, because the default behavior is for the new thread to inherit properties of the parent, and with isolcpus the scheduler doesn't arbitrate the designated cpus, so the new thread will never get a chance to run and change its attributes. -- Chris Cleeland
participants (4)
-
Alexander Carôt -
Chris Cleeland -
Gavin Lambert -
Juan Ramírez