tree 6c70e445ecca767aa9096c2afc28f2eb6e93a4b3
parent 4556eb98104c3e2f1afed2fc507ed19c6162cff5
author Sameer Agarwal <sameeragarwal@google.com> 1524247368 -0700
committer Sameer Agarwal <sameeragarwal@google.com> 1524247368 -0700

Fix a use after free bug in the tests.

The way the SystemTest fixture works is that it takes
a "FooProblem" object as a type, which contains a ceres::Problem
and a ceres::Solver::Options object.

The Options object also contains a linear_solver_ordering which
contains double* which refer to memory that is allocated when
a problem object is created.

So it is important that the lifetime of the ceres::Problem object
and the ceres::Solver::Options object be tied together. But we were
violating this by creating a FooProblem object on the stack, grabbing
its Options struct and passing it to the SystemTest fixture, which
would then create another instance of FooProblem, grab its Problem
object and copy the modified options struct into it.

In the case where a user provided ordering was being used,
this ordering would now be referring to memory allocated by the first
FooProblem object, which would cause Ceres's internal ApplyOrdering
function to fail.

The fix is ofcourse to Problem and Options object that are born
together.

Change-Id: I07c377a9d5fcabbb6c7ca8aa3460206ce045ffa9