The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
Hi Ola,
Thank you for raising this issue on ROS answers.
I have confirmed that this is indeed a Boost issue, and decided to 'take the red pill' to find the root cause...
Pylon statically links against some Boost libraries that are also linked into your ROS node by rosbuild. The issue here is that the statically linked Boost symbols are exposed in the dynamic symbol table of the Pylon driver (libpylonbase.so), and these collide with the system library symbols. The linker will always use the first loaded symbol, which depends on the order in which ld.so loads the libraries.
When ROS used Boost 1.38 everything was fine because the linker could find every required Boost symbol in either one of the library versions (depending on which was loaded first) - i.e. all symbols would be bound to either Pylon's statically linked version, or the system version. In this situation, all calls are ABI compatible and any stateful data in the library would remain consistent because only one library is referenced.
Of course, the Boost API typically changes between versions, so when different Boost versions are linked (e.g.: 1.38 in Pylon and 1.40 in Diamondback), the linker can no longer resolve all symbols to a single library. Here the Boost symbols common to both versions are bound to the first loaded library version, and those symbols missing in the first library are bound to the second! This is a very bad situation because even slight changes to the library can render the calls ABI incompatible (even though they are API compatible). Even if the calls are ABI compatible, any global state in the library would be in mortal danger of corruption due to unexpected calling sequences.
For me this 'bug' typically manifests itself as a segfault due to a null pointer dereference in free(), for you it manifests slightly differently, but has the same root cause.
Although the Boost libraries are 'statically' linked in libpylonbase.so, the symbols are present in the dynamic symbol table, which cannot be modified once the .so has been created (i.e. by the end-user). This means that the end-user cannot hide or obfuscate the offending Boost symbols without an obscene amount of effort. The only practical solution is for Basler to statically link a 'private' version of Boost, as suggested by this stackoverflow post.
Basler is aware of this issue:
We have verified with Basler AG that this issue is known and the problem will be fixed with a future release of Pylon.
In the meantime, the workaround will be to use v1.38 of the Boost libraries. This works fine with Pylon 2.3.
I hope you will be able to use the workaround method for now, please let us know if you have further queries.
-- excerpt of email from Basler Asia Support bc.support.asia@baslerweb.com
Of course no release date was specified, so in the short-term this does not help us write a ROS wrapper for Pylon!
I am currently working on a solution where the ROS node forks off a (non-ROS) Pylon driver wrapper process. This gets around the linking issue. Image data and parameters are transferred using shared memory and controlled with semaphores. This is a fairly unpalatable solution, but it should work.
Cheers,
Fred.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
