[Bug libstdc++/89591] New: How can thread.joinable() reliably work if the pthread_t id is not initialized?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89591
Bug ID: 89591
Summary: How can thread.joinable() reliably work if the
pthread_t id is not initialized?
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: bique.alexandre at gmail dot com
Target Milestone: ---
Hi,
I've been reading the header and I've found that the thread id of
std::thread is not initialized, I hope that I'm wrong and I missed something.
So I wonder how std::thread.joinable() can work?
On top of that, pthread_t has no "invalid thread id" or "uninitialized thread
id" value. So I wonder how the whole logic can work.
To me if your only attribute is pthread_t, you can't know figure anything about
the thread, and even if the thread exists, there is no guarantee that the
current std::thread object created it: if you create a object: std::thread t;
then t.id will be uninitialized, so could very well point to an existing thread
right?
Regards,
Alex
From the header:
thread() noexcept = default;
and also:
typedef __gthread_t native_handle_type;
/// thread::id
class id
{
native_handle_type_M_thread;
public:
id() noexcept : _M_thread() { }
explicit
id(native_handle_type __id) : _M_thread(__id) { }
private:
friend class thread;
friend class hash;
friend bool
operator==(thread::id __x, thread::id __y) noexcept;
friend bool
operator<(thread::id __x, thread::id __y) noexcept;
template
friend basic_ostream<_CharT, _Traits>&
operator<<(basic_ostream<_CharT, _Traits>& __out, thread::id __id);
};
private:
id _M_id;
and then later:
typedef pthread_t __gthread_t;
[Bug libstdc++/89591] How can thread.joinable() reliably work if the pthread_t id is not initialized?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89591
--- Comment #2 from Alexandre Bique ---
> It's initialized here:
>
>> id() noexcept : _M_thread() { }
I did not know that it would initialize it to 0.
In that case let's hope that pthread_t == "value-initialized" will never
happen.
Thank you for answering my question, and I think we can close the bug.
Regards,
Alex
[Bug c++/82164] New: AddressSanitizer: stack-buffer-overflow while constructing std::regex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82164
Bug ID: 82164
Summary: AddressSanitizer: stack-buffer-overflow while
constructing std::regex
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bique.alexandre at gmail dot com
Target Milestone: ---
Hi,
I'd like to report a bug regarding libstdc++ crashing in the regex engine:
Compiling this:
const std::regex kNewLineEscaped("(rn)|(n)|(r)");
const std::regex kNewLineRaw("[\n\r]+", std::regex::basic |
std::regex::optimize);
const std::regex kTabRaw("[\t]");
const std::regex kComma("[,]");
const std::regex kSlash("[/]");
Will generate the following error at runtime:
==6700==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffce71cd978 at pc 0x7f31c9b2402d bp 0x7ffce71cd890 sp
0x7ffce71cd880
WRITE of size 8 at 0x7ffce71cd978 thread T0
#0 0x7f31c9b2402c in _Deque_iterator
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/stl_deque.h:153
#1 0x7f31c9b24b6f in
std::deque
>, std::allocator
> > >::begin()
> > >/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/stl_deque.h:1167
#2 0x7f31c9b24a34 in ~deque
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/stl_deque.h:1045
#3 0x7f31c9ac3554 in ~stack
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/stl_stack.h:99
#4 0x7f31c9ac1824 in _Compiler
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/regex_compiler.tcc:90
#5 0x7f31c9ac112d in
_ZNSt8__detail13__compile_nfaIPKcNSt7__cxx1112regex_traitsIcNSt9enable_ifIXsr27__is_contiguous_normal_iterIT_EE5valueESt10shared_ptrIKNS_4_NFAIT0_4typeES7_S7_RKNSA_11locale_typeENSt15regex_constants18syntax_option_typeE
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/regex_compiler.h:203
#6 0x7f31c9ac0e33 in basic_regex
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/regex.h:768
#7 0x7f31c9ac0986 in basic_regex
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/regex.h:512
#8 0x7f31c9abf336 in basic_regex
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/regex.h:445
#9 0x7f31c97606fb in __cxx_global_var_init.6
../../AudioModulesFrame/AM_StdLibExtensions.cpp:11
#10 0x7f31c976084d in _GLOBAL__sub_I_AM_StdLibExtensions.cpp
../../AudioModulesFrame/AM_StdLibExtensions.cpp
#11 0x7f31d0329579 in call_init.part.0 (/lib64/ld-linux-x86-64.so.2+0xf579)
#12 0x7f31d0329685 in _dl_init (/lib64/ld-linux-x86-64.so.2+0xf685)
#13 0x7f31d032db5d in dl_open_worker (/lib64/ld-linux-x86-64.so.2+0x13b5d)
#14 0x7f31ce54beb3 in __GI__dl_catch_error (/usr/lib/libc.so.6+0x131eb3)
#15 0x7f31d032d379 in _dl_open (/lib64/ld-linux-x86-64.so.2+0x13379)
#16 0x7f31cef52e85 (/usr/lib/libdl.so.2+0xe85)
#17 0x7f31ce54beb3 in __GI__dl_catch_error (/usr/lib/libc.so.6+0x131eb3)
#18 0x7f31cef53586 (/usr/lib/libdl.so.2+0x1586)
#19 0x7f31cef52f21 in dlopen (/usr/lib/libdl.so.2+0xf21)
#20 0x7f31cf3abd98 in __interceptor_dlopen
/build/gcc-multilib/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:5364
#21 0x55abc3a21cb7 in Vst2Plugin::loadDLL()
(/home/abique/develop/bitwig/alex-future/target/bin/release/BitwigPluginHost64+0xa8cb7)
#22 0x55abc3a2218e in Vst2PluginApi::loadPlugin(PluginHost*,
base::core::String)
(/home/abique/develop/bitwig/alex-future/target/bin/release/BitwigPluginHost64+0xa918e)
#23 0x55abc39cc7d5 in PluginHost::getPlugin(base::core::String
const&)
(/home/abique/develop/bitwig/alex-future/target/bin/release/BitwigPluginHost64+0x537d5)
#24 0x55abc39d41a1 in writePluginInfo(base::core::String,
base::core::OutputStream*)
(/home/abique/develop/bitwig/alex-future/target/bin/release/BitwigPluginHost64+0x5b1a1)
#25 0x55abc39bb47f in main
(/home/abique/develop/bitwig/alex-future/target/bin/release/BitwigPluginHost64+0x4247f)
#26 0x7f31ce43af69 in __libc_start_main (/usr/lib/libc.so.6+0x20f69)
#27 0x55abc39be9d9 in _start
(/home/abique/develop/bitwig/alex-future/target/bin/release/BitwigPluginHost64+0x459d9)
Address 0x7ffce71cd978 is located in stack of thread T0 at offset 56 in frame
#0 0x7f31c9b2493f in ~deque
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/stl_deque.h:1045
This frame has 2 object(s):
[32, 64) 'agg.tmp' <== Memory access at offset 56 is inside this variable
[96, 128) 'agg.tmp2'
HINT: this may be a false positive if your program uses some custom
stack unwin
