ceres-solver 1.9.0 from MacPorts segfaults on a particular problem

Question

Original issue 150 created by sandwichmaker on 2014-08-13T16:15:11.000Z:

What steps will reproduce the problem? 1. Install ceres-solver with MacPorts (either from binary with "port install ceres-solver" or source with "port -s install ceres-solver"). 2. Compile the program at http://julianpanetta.com/macports_bugs/test_ceres.cc with /usr/bin/clang++: /usr/bin/clang++ -g -O0 -std=c++11 -I/opt/local/include -I/opt/local/include/eigen3 test_ceres.cc -L/opt/local/lib -lceres -lglog -lgflags -lcholmod -lcxsparse -framework accelerate -o broken 3) ./broken

What is the expected output? What do you see instead?

It should print 0..19, but it intermittently segfaults partway through or throws a std::length error because Ceres has scribbled over the arrays v1s and v2s.

What version of the product are you using? On what operating system?

I've tried with 1.9.0 installed from MacPorts on both OS 10.9.3 and 10.9.4.

Please provide any additional information below.

I've filed a ticket with MacPorts because this only seems to happen with a MacPorts-installed (statically linked) Ceres. The test program runs fine when statically linked against a Ceres version manually built with cmake (both the git head, and the stable 1.9.0 release). However, the MacPorts configuration is so minimal it's unclear where the problem could be. More details are at:

https://trac.macports.org/ticket/44627

该提问来源于开源项目：ceres-solver/ceres-solver

Answer 1

Comment #1 originally posted by sandwichmaker on 2014-08-13T16:20:23.000Z:

Thanks Julian.

I am adding Keir and Julian to the thread. They may know about this.

I tried the code myself and it did not generate any problems. I think you are right in suspecting that there is something about how macports is building this library that is the problem.