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(QFlagsQEventLoop::ProcessEventsFlag) + 2120 (qcocoaeventdispatcher.mm:431) 10 org.qt-project.QtCore 0x000000010f637d36 QEventLoop::exec(QFlagsQEventLoop::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" An: boost-users@lists.boost.org Cc: "Alexander Carôt" 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

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" An: boost-users@lists.boost.org Cc: "Gavin Lambert" 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