[ https://issues.apache.org/jira/browse/MESOS-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Neil Conway updated MESOS-3335: ------------------------------- Description: Per [#3328], ubsan detects the following problem: [ RUN ] FaultToleranceTest.ReregisterCompletedFrameworks /mesos/3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp:303:25: runtime error: load of value 33, which is not a valid value for type 'bool' I believe what is going on here is the following: * The test calls StartMaster(), which does MesosTest::CreateMasterFlags() * MesosTest::CreateMasterFlags() allocates a new master::Flags on the stack, which is subsequently copy-constructed back to StartMaster() * The FlagsBase constructor is: bq. {{FlagsBase() { add(&help, "help", "...", false); }}} where "help" is a member variable -- i.e., it is allocated on the stack in this case. * {{FlagsBase()::add}} captures {{&help}}, e.g.: {noformat} flag.stringify = [t1](const FlagsBase&) -> Option<std::string> { return stringify(*t1); };}} {noformat} * The implicit copy constructor for FlagsBase is just going to copy the lambda above, i.e., the result of the copy constructor will have a lambda that points into MesosTest::CreateMasterFlags()'s stack frame, which is bad news. Not sure the right fix -- comments welcome. You could define a copy-ctor for FlagsBase that does something gross (basically remove the old help flag and define a new one that points into the target of the copy), but that seems, well, gross. Probably not a pressing-problem to fix -- AFAICS worst symptom is that we end up reading one byte from some random stack location when serving {{state.json}}, for example. was: Per [#3328], ubsan detects the following problem: [ RUN ] FaultToleranceTest.ReregisterCompletedFrameworks /mesos/3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp:303:25: runtime error: load of value 33, which is not a valid value for type 'bool' I believe what is going on here is the following: * The test calls StartMaster(), which does MesosTest::CreateMasterFlags() * MesosTest::CreateMasterFlags() allocates a new master::Flags on the stack, which is subsequently copy-constructed back to StartMaster() * The FlagsBase constructor is: bq. {{FlagsBase() { add(&help, "help", "...", false); }}} where "help" is a member variable -- i.e., it is allocated on the stack in this case. * {{FlagsBase()::add}} captures {{&help}}, e.g.: {noformat} flag.stringify = [t1](const FlagsBase&) -> Option<std::string> { return stringify(*t1); };}} {noformat} * The implicit copy constructor for FlagsBase is just going to copy the lambda above, i.e., the result of the copy constructor will have a lambda that points into MesosTest::CreateMasterFlags()'s stack frame, which is bad news. Not sure the right fix -- comments welcome. You could define a copy-ctor for FlagsBase that does something gross (basically remove the old help flag and define a new one that points into the target of the copy), but that seems less, well, gross. Probably not a pressing-problem to fix -- AFAICS worst symptom is that we end up reading one byte from some random stack location when serving {{state.json}}, for example. > FlagsBase copy-ctor leads to dangling pointer > --------------------------------------------- > > Key: MESOS-3335 > URL: https://issues.apache.org/jira/browse/MESOS-3335 > Project: Mesos > Issue Type: Bug > Reporter: Neil Conway > Priority: Minor > Attachments: lambda_capture_bug.cpp > > > Per [#3328], ubsan detects the following problem: > [ RUN ] FaultToleranceTest.ReregisterCompletedFrameworks > /mesos/3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp:303:25: > runtime error: load of value 33, which is not a valid value for type 'bool' > I believe what is going on here is the following: > * The test calls StartMaster(), which does MesosTest::CreateMasterFlags() > * MesosTest::CreateMasterFlags() allocates a new master::Flags on the stack, > which is subsequently copy-constructed back to StartMaster() > * The FlagsBase constructor is: > bq. {{FlagsBase() { add(&help, "help", "...", false); }}} > where "help" is a member variable -- i.e., it is allocated on the stack in > this case. > * {{FlagsBase()::add}} captures {{&help}}, e.g.: > {noformat} > flag.stringify = [t1](const FlagsBase&) -> Option<std::string> { > return stringify(*t1); > };}} > {noformat} > * The implicit copy constructor for FlagsBase is just going to copy the > lambda above, i.e., the result of the copy constructor will have a lambda > that points into MesosTest::CreateMasterFlags()'s stack frame, which is bad > news. > Not sure the right fix -- comments welcome. You could define a copy-ctor for > FlagsBase that does something gross (basically remove the old help flag and > define a new one that points into the target of the copy), but that seems, > well, gross. > Probably not a pressing-problem to fix -- AFAICS worst symptom is that we end > up reading one byte from some random stack location when serving > {{state.json}}, for example. -- This message was sent by Atlassian JIRA (v6.3.4#6332)