[MacPorts] #44627: ceres-solver @1.9.0 library segfaults
MacPorts
noreply at macports.org
Wed Aug 13 02:18:47 PDT 2014
#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
More information about the macports-tickets
mailing list