[jira] [Updated] (MESOS-3335) FlagsBase copy-ctor leads to dangling pointer.
[ https://issues.apache.org/jira/browse/MESOS-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-3335: -- Sprint: Mesosphere Sprint 44, Mesosphere Sprint 45 (was: Mesosphere Sprint 44) > 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 >Assignee: Benjamin Bannier > Labels: mesosphere > 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 { > 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)
[jira] [Updated] (MESOS-3335) FlagsBase copy-ctor leads to dangling pointer.
[ https://issues.apache.org/jira/browse/MESOS-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-3335: -- Story Points: 8 > 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 >Assignee: Benjamin Bannier > Labels: mesosphere > 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 { > 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)
[jira] [Updated] (MESOS-3335) FlagsBase copy-ctor leads to dangling pointer.
[ https://issues.apache.org/jira/browse/MESOS-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bannier updated MESOS-3335: Sprint: Mesosphere Sprint 44 > 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 >Assignee: Benjamin Bannier > Labels: mesosphere > 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 { > 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)
[jira] [Updated] (MESOS-3335) FlagsBase copy-ctor leads to dangling pointer.
[ https://issues.apache.org/jira/browse/MESOS-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bannier updated MESOS-3335: Shepherd: Michael Park > 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 >Assignee: Benjamin Bannier > Labels: mesosphere > 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 { > 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)
[jira] [Updated] (MESOS-3335) FlagsBase copy-ctor leads to dangling pointer.
[ https://issues.apache.org/jira/browse/MESOS-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-3335: --- Labels: mesosphere (was: ) Priority: Major (was: Minor) Summary: FlagsBase copy-ctor leads to dangling pointer. (was: FlagsBase copy-ctor leads to dangling pointer) > 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 >Assignee: Benjamin Bannier > Labels: mesosphere > 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 { > 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)
[jira] [Updated] (MESOS-3335) FlagsBase copy-ctor leads to dangling pointer
[ 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 { 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 { 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 { > 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, >
[jira] [Updated] (MESOS-3335) FlagsBase copy-ctor leads to dangling pointer
[ https://issues.apache.org/jira/browse/MESOS-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Conway updated MESOS-3335: --- Attachment: lambda_capture_bug.cpp Attached a reduced test case that demonstrates the problem. > 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 { > 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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)