C++11 multithreading: Valgrind uninitialized value(s) warning
up vote
1
down vote
favorite
I have compiled the following dummy program under Linux using gcc 8.2.1:
#include <iostream>
#include <mutex>
#include <thread>
struct Foo
void start()
thread = std::thread(&Foo::run, this);
void stop()
mutex.lock();
done = true;
mutex.unlock();
thread.join();
void run()
bool tmp;
for (;;)
mutex.lock();
tmp = done;
mutex.unlock();
if (tmp)
break;
std::thread thread;
std::mutex mutex;
bool done;
;
int main()
Foo foo;
std::cout << "starting...n";
foo.start();
std::cout << "stopping...n";
foo.stop();
std::cout << "donen";
If I subsequently run it under valgrind 3.14.0, I receive the following warning:
==30060== Thread 2:
==30060== Conditional jump or move depends on uninitialised value(s)
==30060== at 0x1095F3: Foo::run() (in /.../a.out)
==30060== by 0x109AAE: void std::__invoke_impl<void, void (Foo::*)(), Foo*>(std::__invoke_memfun_deref, void (Foo::*&&)(), Foo*&&) (in /.../a.out)
==30060== by 0x109771: std::__invoke_result<void (Foo::*)(), Foo*>::type std::__invoke<void (Foo::*)(), Foo*>(void (Foo::*&&)(), Foo*&&) (in /.../a.out)
==30060== by 0x10A012: decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (Foo::*)(), Foo*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) (in /.../a.out)
==30060== by 0x109FB8: std::thread::_Invoker<std::tuple<void (Foo::*)(), Foo*> >::operator()() (in /.../a.out)
==30060== by 0x109F8D: std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (Foo::*)(), Foo*> > >::_M_run() (in /.../a.out)
==30060== by 0x496A062: execute_native_thread_routine (thread.cc:80)
==30060== by 0x4894A9C: start_thread (in /usr/lib/libpthread-2.28.so)
==30060== by 0x4CD7A42: clone (in /usr/lib/libc-2.28.so)
I am not completely sure what is causing this, I have written this snippet in hopes of diagnosing a bug in a more complicated class (that I cannot post here) I am currently working on and which produces exceptions when calling the equivalent of Foo::stop()
. Does the valgrind warning imply some serious misunderstanding of the C++ threading interface on my part? And assuming for a moment that Foo::run
would actually do something useful, how could I fix this program while keeping Foo
's interface the way it is?
c++ multithreading c++11 valgrind
add a comment |
up vote
1
down vote
favorite
I have compiled the following dummy program under Linux using gcc 8.2.1:
#include <iostream>
#include <mutex>
#include <thread>
struct Foo
void start()
thread = std::thread(&Foo::run, this);
void stop()
mutex.lock();
done = true;
mutex.unlock();
thread.join();
void run()
bool tmp;
for (;;)
mutex.lock();
tmp = done;
mutex.unlock();
if (tmp)
break;
std::thread thread;
std::mutex mutex;
bool done;
;
int main()
Foo foo;
std::cout << "starting...n";
foo.start();
std::cout << "stopping...n";
foo.stop();
std::cout << "donen";
If I subsequently run it under valgrind 3.14.0, I receive the following warning:
==30060== Thread 2:
==30060== Conditional jump or move depends on uninitialised value(s)
==30060== at 0x1095F3: Foo::run() (in /.../a.out)
==30060== by 0x109AAE: void std::__invoke_impl<void, void (Foo::*)(), Foo*>(std::__invoke_memfun_deref, void (Foo::*&&)(), Foo*&&) (in /.../a.out)
==30060== by 0x109771: std::__invoke_result<void (Foo::*)(), Foo*>::type std::__invoke<void (Foo::*)(), Foo*>(void (Foo::*&&)(), Foo*&&) (in /.../a.out)
==30060== by 0x10A012: decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (Foo::*)(), Foo*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) (in /.../a.out)
==30060== by 0x109FB8: std::thread::_Invoker<std::tuple<void (Foo::*)(), Foo*> >::operator()() (in /.../a.out)
==30060== by 0x109F8D: std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (Foo::*)(), Foo*> > >::_M_run() (in /.../a.out)
==30060== by 0x496A062: execute_native_thread_routine (thread.cc:80)
==30060== by 0x4894A9C: start_thread (in /usr/lib/libpthread-2.28.so)
==30060== by 0x4CD7A42: clone (in /usr/lib/libc-2.28.so)
I am not completely sure what is causing this, I have written this snippet in hopes of diagnosing a bug in a more complicated class (that I cannot post here) I am currently working on and which produces exceptions when calling the equivalent of Foo::stop()
. Does the valgrind warning imply some serious misunderstanding of the C++ threading interface on my part? And assuming for a moment that Foo::run
would actually do something useful, how could I fix this program while keeping Foo
's interface the way it is?
c++ multithreading c++11 valgrind
You could add trace origins to valgrind to try to get more information.
– LuisGP
Nov 10 at 16:37
Surprisingly enough, valgrind's message is clear and straight to the point.tmp = done; ...; if (tmp) ...
, with "Conditional jump or move depends on uninitialised value". There is only one conditional statement in the entire program, which ultimately depends on the value ofdone
.
– Steve
Nov 10 at 16:51
I'm blind, you are right.
– LuisGP
Nov 10 at 16:53
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have compiled the following dummy program under Linux using gcc 8.2.1:
#include <iostream>
#include <mutex>
#include <thread>
struct Foo
void start()
thread = std::thread(&Foo::run, this);
void stop()
mutex.lock();
done = true;
mutex.unlock();
thread.join();
void run()
bool tmp;
for (;;)
mutex.lock();
tmp = done;
mutex.unlock();
if (tmp)
break;
std::thread thread;
std::mutex mutex;
bool done;
;
int main()
Foo foo;
std::cout << "starting...n";
foo.start();
std::cout << "stopping...n";
foo.stop();
std::cout << "donen";
If I subsequently run it under valgrind 3.14.0, I receive the following warning:
==30060== Thread 2:
==30060== Conditional jump or move depends on uninitialised value(s)
==30060== at 0x1095F3: Foo::run() (in /.../a.out)
==30060== by 0x109AAE: void std::__invoke_impl<void, void (Foo::*)(), Foo*>(std::__invoke_memfun_deref, void (Foo::*&&)(), Foo*&&) (in /.../a.out)
==30060== by 0x109771: std::__invoke_result<void (Foo::*)(), Foo*>::type std::__invoke<void (Foo::*)(), Foo*>(void (Foo::*&&)(), Foo*&&) (in /.../a.out)
==30060== by 0x10A012: decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (Foo::*)(), Foo*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) (in /.../a.out)
==30060== by 0x109FB8: std::thread::_Invoker<std::tuple<void (Foo::*)(), Foo*> >::operator()() (in /.../a.out)
==30060== by 0x109F8D: std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (Foo::*)(), Foo*> > >::_M_run() (in /.../a.out)
==30060== by 0x496A062: execute_native_thread_routine (thread.cc:80)
==30060== by 0x4894A9C: start_thread (in /usr/lib/libpthread-2.28.so)
==30060== by 0x4CD7A42: clone (in /usr/lib/libc-2.28.so)
I am not completely sure what is causing this, I have written this snippet in hopes of diagnosing a bug in a more complicated class (that I cannot post here) I am currently working on and which produces exceptions when calling the equivalent of Foo::stop()
. Does the valgrind warning imply some serious misunderstanding of the C++ threading interface on my part? And assuming for a moment that Foo::run
would actually do something useful, how could I fix this program while keeping Foo
's interface the way it is?
c++ multithreading c++11 valgrind
I have compiled the following dummy program under Linux using gcc 8.2.1:
#include <iostream>
#include <mutex>
#include <thread>
struct Foo
void start()
thread = std::thread(&Foo::run, this);
void stop()
mutex.lock();
done = true;
mutex.unlock();
thread.join();
void run()
bool tmp;
for (;;)
mutex.lock();
tmp = done;
mutex.unlock();
if (tmp)
break;
std::thread thread;
std::mutex mutex;
bool done;
;
int main()
Foo foo;
std::cout << "starting...n";
foo.start();
std::cout << "stopping...n";
foo.stop();
std::cout << "donen";
If I subsequently run it under valgrind 3.14.0, I receive the following warning:
==30060== Thread 2:
==30060== Conditional jump or move depends on uninitialised value(s)
==30060== at 0x1095F3: Foo::run() (in /.../a.out)
==30060== by 0x109AAE: void std::__invoke_impl<void, void (Foo::*)(), Foo*>(std::__invoke_memfun_deref, void (Foo::*&&)(), Foo*&&) (in /.../a.out)
==30060== by 0x109771: std::__invoke_result<void (Foo::*)(), Foo*>::type std::__invoke<void (Foo::*)(), Foo*>(void (Foo::*&&)(), Foo*&&) (in /.../a.out)
==30060== by 0x10A012: decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (Foo::*)(), Foo*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) (in /.../a.out)
==30060== by 0x109FB8: std::thread::_Invoker<std::tuple<void (Foo::*)(), Foo*> >::operator()() (in /.../a.out)
==30060== by 0x109F8D: std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (Foo::*)(), Foo*> > >::_M_run() (in /.../a.out)
==30060== by 0x496A062: execute_native_thread_routine (thread.cc:80)
==30060== by 0x4894A9C: start_thread (in /usr/lib/libpthread-2.28.so)
==30060== by 0x4CD7A42: clone (in /usr/lib/libc-2.28.so)
I am not completely sure what is causing this, I have written this snippet in hopes of diagnosing a bug in a more complicated class (that I cannot post here) I am currently working on and which produces exceptions when calling the equivalent of Foo::stop()
. Does the valgrind warning imply some serious misunderstanding of the C++ threading interface on my part? And assuming for a moment that Foo::run
would actually do something useful, how could I fix this program while keeping Foo
's interface the way it is?
c++ multithreading c++11 valgrind
c++ multithreading c++11 valgrind
asked Nov 10 at 16:26
Peter
31719
31719
You could add trace origins to valgrind to try to get more information.
– LuisGP
Nov 10 at 16:37
Surprisingly enough, valgrind's message is clear and straight to the point.tmp = done; ...; if (tmp) ...
, with "Conditional jump or move depends on uninitialised value". There is only one conditional statement in the entire program, which ultimately depends on the value ofdone
.
– Steve
Nov 10 at 16:51
I'm blind, you are right.
– LuisGP
Nov 10 at 16:53
add a comment |
You could add trace origins to valgrind to try to get more information.
– LuisGP
Nov 10 at 16:37
Surprisingly enough, valgrind's message is clear and straight to the point.tmp = done; ...; if (tmp) ...
, with "Conditional jump or move depends on uninitialised value". There is only one conditional statement in the entire program, which ultimately depends on the value ofdone
.
– Steve
Nov 10 at 16:51
I'm blind, you are right.
– LuisGP
Nov 10 at 16:53
You could add trace origins to valgrind to try to get more information.
– LuisGP
Nov 10 at 16:37
You could add trace origins to valgrind to try to get more information.
– LuisGP
Nov 10 at 16:37
Surprisingly enough, valgrind's message is clear and straight to the point.
tmp = done; ...; if (tmp) ...
, with "Conditional jump or move depends on uninitialised value". There is only one conditional statement in the entire program, which ultimately depends on the value of done
.– Steve
Nov 10 at 16:51
Surprisingly enough, valgrind's message is clear and straight to the point.
tmp = done; ...; if (tmp) ...
, with "Conditional jump or move depends on uninitialised value". There is only one conditional statement in the entire program, which ultimately depends on the value of done
.– Steve
Nov 10 at 16:51
I'm blind, you are right.
– LuisGP
Nov 10 at 16:53
I'm blind, you are right.
– LuisGP
Nov 10 at 16:53
add a comment |
1 Answer
1
active
oldest
votes
up vote
5
down vote
accepted
What is the initial value of bool done;
? It is indeterminate (some garbage value), so your thread (run
) can be stopped without calling stop
method.
done
must be initialized:
//...
std::mutex mutex;
bool done = false; // <--
Oh wow, I feel stupid now. That's it, I was thrown of by the cryptic valgrind output.
– Peter
Nov 10 at 17:19
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
accepted
What is the initial value of bool done;
? It is indeterminate (some garbage value), so your thread (run
) can be stopped without calling stop
method.
done
must be initialized:
//...
std::mutex mutex;
bool done = false; // <--
Oh wow, I feel stupid now. That's it, I was thrown of by the cryptic valgrind output.
– Peter
Nov 10 at 17:19
add a comment |
up vote
5
down vote
accepted
What is the initial value of bool done;
? It is indeterminate (some garbage value), so your thread (run
) can be stopped without calling stop
method.
done
must be initialized:
//...
std::mutex mutex;
bool done = false; // <--
Oh wow, I feel stupid now. That's it, I was thrown of by the cryptic valgrind output.
– Peter
Nov 10 at 17:19
add a comment |
up vote
5
down vote
accepted
up vote
5
down vote
accepted
What is the initial value of bool done;
? It is indeterminate (some garbage value), so your thread (run
) can be stopped without calling stop
method.
done
must be initialized:
//...
std::mutex mutex;
bool done = false; // <--
What is the initial value of bool done;
? It is indeterminate (some garbage value), so your thread (run
) can be stopped without calling stop
method.
done
must be initialized:
//...
std::mutex mutex;
bool done = false; // <--
answered Nov 10 at 16:35
rafix07
6,3731613
6,3731613
Oh wow, I feel stupid now. That's it, I was thrown of by the cryptic valgrind output.
– Peter
Nov 10 at 17:19
add a comment |
Oh wow, I feel stupid now. That's it, I was thrown of by the cryptic valgrind output.
– Peter
Nov 10 at 17:19
Oh wow, I feel stupid now. That's it, I was thrown of by the cryptic valgrind output.
– Peter
Nov 10 at 17:19
Oh wow, I feel stupid now. That's it, I was thrown of by the cryptic valgrind output.
– Peter
Nov 10 at 17:19
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53240968%2fc11-multithreading-valgrind-uninitialized-values-warning%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You could add trace origins to valgrind to try to get more information.
– LuisGP
Nov 10 at 16:37
Surprisingly enough, valgrind's message is clear and straight to the point.
tmp = done; ...; if (tmp) ...
, with "Conditional jump or move depends on uninitialised value". There is only one conditional statement in the entire program, which ultimately depends on the value ofdone
.– Steve
Nov 10 at 16:51
I'm blind, you are right.
– LuisGP
Nov 10 at 16:53