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?










share|improve this question





















  • 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











  • I'm blind, you are right.
    – LuisGP
    Nov 10 at 16:53














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?










share|improve this question





















  • 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











  • I'm blind, you are right.
    – LuisGP
    Nov 10 at 16:53












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?










share|improve this question













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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 10 at 16:26









Peter

31319




31319











  • 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











  • 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










  • 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















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












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; // <--





share|improve this answer




















  • Oh wow, I feel stupid now. That's it, I was thrown of by the cryptic valgrind output.
    – Peter
    Nov 10 at 17:19










Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















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

























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; // <--





share|improve this answer




















  • Oh wow, I feel stupid now. That's it, I was thrown of by the cryptic valgrind output.
    – Peter
    Nov 10 at 17:19














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; // <--





share|improve this answer




















  • Oh wow, I feel stupid now. That's it, I was thrown of by the cryptic valgrind output.
    – Peter
    Nov 10 at 17:19












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; // <--





share|improve this answer












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; // <--






share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 10 at 16:35









rafix07

5,7881513




5,7881513











  • 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




Oh wow, I feel stupid now. That's it, I was thrown of by the cryptic valgrind output.
– Peter
Nov 10 at 17:19

















 

draft saved


draft discarded















































 


draft saved


draft discarded














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





















































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







這個網誌中的熱門文章

What does pagestruct do in Eviews?

Dutch intervention in Lombok and Karangasem

Channel Islands