https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63614
--- Comment #3 from dyle at dyle dot org --- (In reply to Jonathan Wakely from comment #2) > (In reply to dyle from comment #0) > > Is this a gcc bug? Is it possible that std::this_thread::get_id() SIGSEVs? > > Yes it's possible if you don't use -pthread to link to libpthread. Ok. I'll attach it then. > > (Yes, there's a race condition on std::cout. But this is not the point.) Is > > there a drawback by creating a threads that way and could there be any > > correlation to my sigsev? > > No, it's unlikely. > > You can rule that out by using std::thread(&A::foo, this) Good, I'll use this pattern then. I do not sense any pros/cons compared to my previous lambda approach. > (In reply to dyle from comment #1) > > Huh. It ain't std::this_thread::get_id(), it is the assignment! > > Because this > > > > auto nThread = 1; > > > > as first statement in the thread crashes also. o.O > > Then that's unlikely to be a GCC bug, are you running out of stack, or > scribbling on the stack from another function? Not that I'm aware of. I always try to be extra cautious and super paranoid, hence my compiler flags: -Wall -Wextra -Werror -pedantic. But these ain't no silver bullets either. > Have you tried using valgrind, or asan, or -fstack-protector ? Good idea. I'll go for these tomorrow. Thx.
