[MacPorts] #44627: ceres-solver @1.9.0 library segfaults
#44627: ceres-solver @1.9.0 library segfaults ------------------------------+-------------------------------- Reporter: julian.panetta@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Keywords: mavericks | Port: ceres-solver ------------------------------+-------------------------------- Installing Ceres through MacPorts and then compiling the following program with the built-in clang on Mac OS 10.9.{3,4} results in intermittent segfault/errors (it seems Ceres is scribbling over memory): http://julianpanetta.com/macports_bugs/test_ceres.cc {{{ $ /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 $ ./broken 0 1 [1] 75517 segmentation fault ./broken $ ./broken 0 1 2 3 libc++abi.dylib: terminating with uncaught exception of type std::length_error: vector [1] 75515 abort ./broken }}} Sometimes the program runs to completion, but usually it segfaults in the ceres::Solve call. The std::length_error shown above is much more rare (happens because vectors v1s and v2s are getting scribbled over). This was a very difficult bug to track down, and unfortunately I haven't been able to simplify the test case further. I am filing the bug here rather than upstream because the following setups do not exhibit the problem, leading me to suspect the error is in the MacPorts build: 1) Building ceres-solver manually (both from git repo, and from "latest stable release" link at ceres-solver.org), compiling test_ceres.cc with /usr/bin/clang;[[BR]] 2) Compiling test_ceres.cc with clang-mp-3.{4,5}, linking against MacPorts libceres.a Those made me suspect an ABI incompatibility with the MacPorts binary, but strangely... * Doesn't work: Installing ceres-solver from source MacPorts (using the -s option), compiling test_ceres.cc with /usr/bin/clang * Works: Building ceres-solver manually using /usr/bin/clang, compiling test_ceres.cc with macports clang 3.{4,5} * Works: Building ceres-solver manually using clang-mp-3.4, compiling test_ceres.cc with /usr/bin/clang * Fails to link: Building ceres-solver manually using clang-mp-3.5, compiling test_ceres.cc with with any compiler (including clang-mp-3.5!) In summary, manually building ceres-solver using cmake works in all cases I tested regardless of compiler (except the link failure case), while installing through MacPorts (from either binary or source) only works with clang-mp-3.{4,5} and not /usr/bin/clang. To me this suggests there's something wrong with how MacPorts configures ceres-solver, but if we decide that the bug lies upstream I'm happy to report the issue at https://code.google.com/p/ceres-solver/issues/list For reference, my "built-in" clang is: $ clang++ --version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.2.0 Thread model: posix -- Ticket URL: <https://trac.macports.org/ticket/44627> MacPorts <http://www.macports.org/> Ports system for OS X
#44627: ceres-solver @1.9.0 library segfaults -------------------------------+----------------------- Reporter: julian.panetta@… | Owner: mmoll@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: | Keywords: mavericks Port: ceres-solver | -------------------------------+----------------------- Changes (by ryandesign@…): * cc: mmoll@… (removed) * owner: macports-tickets@… => mmoll@… Old description:
Installing Ceres through MacPorts and then compiling the following program with the built-in clang on Mac OS 10.9.{3,4} results in intermittent segfault/errors (it seems Ceres is scribbling over memory):
http://julianpanetta.com/macports_bugs/test_ceres.cc
{{{ $ /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 $ ./broken 0 1 [1] 75517 segmentation fault ./broken $ ./broken 0 1 2 3 libc++abi.dylib: terminating with uncaught exception of type std::length_error: vector [1] 75515 abort ./broken }}} Sometimes the program runs to completion, but usually it segfaults in the ceres::Solve call. The std::length_error shown above is much more rare (happens because vectors v1s and v2s are getting scribbled over). This was a very difficult bug to track down, and unfortunately I haven't been able to simplify the test case further. I am filing the bug here rather than upstream because the following setups do not exhibit the problem, leading me to suspect the error is in the MacPorts build:
1) Building ceres-solver manually (both from git repo, and from "latest stable release" link at ceres-solver.org), compiling test_ceres.cc with /usr/bin/clang;[[BR]] 2) Compiling test_ceres.cc with clang-mp-3.{4,5}, linking against MacPorts libceres.a
Those made me suspect an ABI incompatibility with the MacPorts binary, but strangely... * Doesn't work: Installing ceres-solver from source MacPorts (using the -s option), compiling test_ceres.cc with /usr/bin/clang * Works: Building ceres-solver manually using /usr/bin/clang, compiling test_ceres.cc with macports clang 3.{4,5} * Works: Building ceres-solver manually using clang-mp-3.4, compiling test_ceres.cc with /usr/bin/clang * Fails to link: Building ceres-solver manually using clang-mp-3.5, compiling test_ceres.cc with with any compiler (including clang-mp-3.5!)
In summary, manually building ceres-solver using cmake works in all cases I tested regardless of compiler (except the link failure case), while installing through MacPorts (from either binary or source) only works with clang-mp-3.{4,5} and not /usr/bin/clang. To me this suggests there's something wrong with how MacPorts configures ceres-solver, but if we decide that the bug lies upstream I'm happy to report the issue at https://code.google.com/p/ceres-solver/issues/list
For reference, my "built-in" clang is: $ clang++ --version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.2.0 Thread model: posix
New description: Installing Ceres through MacPorts and then compiling the following program with the built-in clang on Mac OS 10.9.{3,4} results in intermittent segfault/errors (it seems Ceres is scribbling over memory): http://julianpanetta.com/macports_bugs/test_ceres.cc {{{ $ /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 $ ./broken 0 1 [1] 75517 segmentation fault ./broken $ ./broken 0 1 2 3 libc++abi.dylib: terminating with uncaught exception of type std::length_error: vector [1] 75515 abort ./broken }}} Sometimes the program runs to completion, but usually it segfaults in the ceres::Solve call. The std::length_error shown above is much more rare (happens because vectors v1s and v2s are getting scribbled over). This was a very difficult bug to track down, and unfortunately I haven't been able to simplify the test case further. I am filing the bug here rather than upstream because the following setups do not exhibit the problem, leading me to suspect the error is in the MacPorts build: 1. Building ceres-solver manually (both from git repo, and from "latest stable release" link at ceres-solver.org), compiling test_ceres.cc with /usr/bin/clang; 2. Compiling test_ceres.cc with clang-mp-3.{4,5}, linking against MacPorts libceres.a Those made me suspect an ABI incompatibility with the MacPorts binary, but strangely... * Doesn't work: Installing ceres-solver from source MacPorts (using the -s option), compiling test_ceres.cc with /usr/bin/clang * Works: Building ceres-solver manually using /usr/bin/clang, compiling test_ceres.cc with macports clang 3.{4,5} * Works: Building ceres-solver manually using clang-mp-3.4, compiling test_ceres.cc with /usr/bin/clang * Fails to link: Building ceres-solver manually using clang-mp-3.5, compiling test_ceres.cc with with any compiler (including clang-mp-3.5!) In summary, manually building ceres-solver using cmake works in all cases I tested regardless of compiler (except the link failure case), while installing through MacPorts (from either binary or source) only works with clang-mp-3.{4,5} and not /usr/bin/clang. To me this suggests there's something wrong with how MacPorts configures ceres-solver, but if we decide that the bug lies upstream I'm happy to report the issue at https://code.google.com/p/ceres-solver/issues/list For reference, my "built-in" clang is: {{{ $ clang++ --version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.2.0 Thread model: posix }}} -- -- Ticket URL: <https://trac.macports.org/ticket/44627#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X
#44627: ceres-solver @1.9.0 library segfaults -------------------------------+----------------------- Reporter: julian.panetta@… | Owner: mmoll@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: | Keywords: mavericks Port: ceres-solver | -------------------------------+----------------------- Comment (by mmoll@…): I can reproduce the problem. The portfile for ceres-solver is pretty minimal, so I doubt the problem is there. It could be somewhere else in MacPorts (env variables, cmake arguments), but it could just as easily be in ceres-solver. Could you file an upstream ticket? It'd nice to know if this is something that has already been fixed (or is a known problem). You can reference this ticket. -- Ticket URL: <https://trac.macports.org/ticket/44627#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X
#44627: ceres-solver @1.9.0 library segfaults -------------------------------+----------------------- Reporter: julian.panetta@… | Owner: mmoll@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: | Keywords: mavericks Port: ceres-solver | -------------------------------+----------------------- Comment (by julian.panetta@…): Thanks for trying it. I filed an issue at: https://code.google.com/p/ceres-solver/issues/detail?id=150 -- Ticket URL: <https://trac.macports.org/ticket/44627#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts