danini / progressive-x

The Progressive-X algorithm proposed in paper: Daniel Barath and Jiri Matas; Progressive-X: Efficient, Anytime, Multi-Model Fitting Algorithm, International Conference on Computer Vision, 2019. It is available at https://arxiv.org/pdf/1906.02290
MIT License
71 stars 17 forks source link

Segmentation Fault in FundamentalMatrixSevenPointSolver #11

Open fkluger opened 1 year ago

fkluger commented 1 year ago

Hi,

I am running some experiments with F-Matrix estimation and am occasionally encountering segmentation faults.

GDB gave me this:

#0  gcransac::estimator::solver::FundamentalMatrixSevenPointSolver::estimateModel (this=this@entry=0x7fffffff9da8, data_=..., sample_=sample_@entry=0x0, sample_number_=7, models_=..., weights_=weights_@entry=0x0)
    at /home/kluger/projects/remote/progressive-x/graph-cut-ransac/src/pygcransac/include/estimators/solver_fundamental_matrix_seven_point.h:103
103                                             const int sample_idx = sample_[i];

(gdb) p sample_
$7 = (const size_t *) 0x0

So sample_ appears to be nullptr and FundamentalMatrixSevenPointSolver::estimateModel does not handle this.

I noticed this case is handled in FundamentalMatrixBundleAdjustmentSolver::estimateModel:

if (sample_ == nullptr)
    sample_number_ = data_.rows;

If sample_number_ is greater than seven, the Eight-Point-Solver is used instead.

However, in this particular case:

(gdb) p data_.rows
$8 = 7

So the Seven-Point-Solver is still called because sample_number_ = 7, which then segfaults because sample_ = nullptr.

I will try adding another check to FundamentalMatrixSevenPointSolver::estimateModel for sample_ == nullptr to avoid the segfault, but I don't know if this is the correct way to fix this bug.

Best wishes, Florian