[Ros-release] ABI compatibility

Vijay Pradeep vijay at hidof.com
Thu Jan 3 20:30:38 UTC 2013

Hi Brian,

Wim and I have been working on a project with some of the folks at Willow
Garage to restructure some of the internals of pr2_mechanism.  We've been
very careful in ensuring that we keep API compatibility with the previous
releases.  Unfortunately, however, we were unaware of the ABI compatibility
requirements specified in REP 9.  Our changes included an ABI breaking
change in pr2_mechanism, which would cause all sorts of memory errors for
anyone that compiled against an old pr2_mechanism deb and then upgraded it.
 We're sorry for introducing that bug into your system.

Given that we've already released this ABI breaking change and reverting
would result in another ABI breaking change, I think that keeping the
latest version of pr2_mechanism in the release is our best way to proceed.

In this case, we knew we were making an ABI breaking change, and we could
have saved you a bunch of debugging time by sending out an email mentioning
the ABI change.  However, in many cases, I think developers may not even
realize that they're making this sort of breaking change.  Without some
sort of automated ABI checking, it may be hard to enforce REP 9.

I'm sorry again for putting you on this segfaulting, glibc corrupting,
memory error hunt.  Please let me know if there's anything we can do to

Vijay Pradeep
hiDOF, Inc.

On Thu, Jan 3, 2013 at 11:01 AM, Brian Gerkey <gerkey at osrfoundation.org>wrote:

> hi,
> We recently experienced the following problem: a binary deb that we
> build against ROS Fuerte started producing mysterious crashes when
> installed on a fresh system.  It had previously been working fine, and
> still worked fine on some not-freshly installed systems.
> After a bit of head-scratching, we hypothesized that something had
> changed in the underlying Fuerte debs.  So we tried compiling our
> code, without changes, against the latest Fuerte debs.  That worked
> fine.  So we did a no-op re-release of our package, to produce a new
> deb built against the latest Fuerte debs.  That works fine, too. So,
> for now, our problem is solved.
> But I'd like to avoid this problem in the future.  I captured the
> relevant dpkg state of a system with the older Fuerte debs installed
> and the same system after removing ros-fuerte-* and reinstalling.  I
> narrowed the differences down to:
> < ii  ros-fuerte-pr2-controllers
> 1.8.0-s1351921336~precise                 PR2 Controllers
> < ii  ros-fuerte-pr2-mechanism
> 1.6.1-s1351920681~precise                 PR2 mechanism
> ---
> > ii  ros-fuerte-pr2-controllers               1.8.1-s1356572075~precise
>               PR2 Controllers
> > ii  ros-fuerte-pr2-mechanism                 1.6.4-s1356571098~precise
>               PR2 mechanism
> I'm guessing that in one or both of those packages, ABI compatibility
> was violated in a release somewhere in the intervening releases.  In
> our code, we're using both of those packages in plugins that load into
> Gazebo, so it makes sense that ABI-breaking changes there would cause
> the crash we were seeing.  I'd like to narrow it down to one or the
> other of those two packages, but I would either need to build from
> source or pull the older debs from somewhere; are old ROS debs
> archived?
> We are guaranteeing ABI compatibility for stable packages within a ROS
> distribution, right?  REP 9 says yes:
> http://www.ros.org/reps/rep-0009.html.  But are developers and
> maintainers aware of that policy?  And are we doing any checking,
> automatic or otherwise, for compatibility?
> While in this case it may have just been an errant change to a stable
> package, it can easily happen again, and it can be painful to debug.
> Any ideas on what to do to better support our use case, where we're
> building debs on top of ROS debs?  I'd really prefer not to replicate
> the strict version-locking system that the ROS debs use; ABI
> compatibility is supposed to make that sort of thing unnecessary.
> As a stopgap measure, it would be enough for us to know when new debs
> go into the public ROS repo.  Maybe an email could go to this list
> when that sync is done?  Then we could trigger rebuilds of our
> ROS-dependent debs.
>     brian.
> p.s. If you care to reproduce the problem, on an Ubuntu 12.04 Precise
> system:
> 1. Add our repo:
> sudo sh -c 'echo "deb http://packages.osrfoundation.org/drc/ubuntu
> precise main" > /etc/apt/sources.list.d/drc-latest.list'
> wget http://packages.osrfoundation.org/drc.key -O - | sudo apt-key add -
> 2. Install drcsim (you'll get the fixed version, 1.3.1):
> sudo apt-get update
> sudo apt-get install drcsim
> 3. Launch the simulation (it should work, displaying a simulation with
> a humanoid robot swaying slightly):
> . /usr/share/drcsim/setup.sh
> roslaunch atlas_utils atlas.launch
> 4. Revert to drcsim 1.3.0:
> sudo apt-get remove drcsim
> wget http://gazebosim.org/assets/distributions/drcsim_1.3.0_amd64.deb
> sudo dpkg -i drcsim_1.3.0_amd64.deb
> 5. Launch the simulation (it should crash, perhaps after briefly
> displaying a simulation with an empty world):
> . /usr/share/drcsim/setup.sh
> roslaunch atlas_utils atlas.launch
> Note: drcsim 1.3.0 and 1.3.1 are very nearly code-identical.  Below is
> a diff of the source tarballs from which the debs were built (you can
> get them from http://gazebosim.org/assets/distributions).  The "Only
> in" differences come from the fact that 1.3.0 was released with an
> older version of a tool that wasn't smart enough to remove detritus
> that the developer had in his or her local working copy.  And I've
> verified that building 1.3.0 from source, with the detritus present,
> against the newer Fuerte debs works fine.
> Only in drcsim-1.3.0: atlas_drc_rename.sh
> diff -ur drcsim-1.3.0/CMakeLists.txt drcsim-1.3.1/CMakeLists.txt
> --- drcsim-1.3.0/CMakeLists.txt 2012-12-21 16:21:45.000000000 -0800
> +++ drcsim-1.3.1/CMakeLists.txt 2013-01-02 21:19:20.000000000 -0800
> @@ -5,7 +5,7 @@
>  message (STATUS "${PROJECT_NAME} version ${DRC_SIM_VERSION_FULL}")
> Only in drcsim-1.3.0: CMakeLists.txt.orig
> Only in drcsim-1.3.1: .hg_archival.txt
> diff -ur drcsim-1.3.0/.hgtags drcsim-1.3.1/.hgtags
> --- drcsim-1.3.0/.hgtags        2012-12-21 16:21:45.000000000 -0800
> +++ drcsim-1.3.1/.hgtags        2013-01-02 21:19:20.000000000 -0800
> @@ -73,4 +73,8 @@
>  1557aec7da4cd5d53febcd81b666689af1732c5f drcsim-prerelease_1.2.1
>  6f896feb2bec52739622e97a7d6cdd518eb2b735 drcsim-prerelease_1.2.1
>  4b10e0f62abb21f1b2a1498738e110623085c29d drcsim-prerelease_1.3.0
> -f0f919ec908db051bb7657e2bd0d8e0d7b06583f drcsim_1.3.0
> +0117103c92002c100b2ccf459f0d791b86054283 drcsim_1.3.1
> +0117103c92002c100b2ccf459f0d791b86054283 drcsim_1.3.1
> +756c72598020b604d8e39fe1db9274b5fc92e8cc drcsim_1.3.1
> +756c72598020b604d8e39fe1db9274b5fc92e8cc drcsim_1.3.1
> +2cdef74a2f7177c0410c1272bee34e1d70ada0da drcsim_1.3.1
> Only in drcsim-1.3.0/models/atlas: drc_robot.gv
> Only in drcsim-1.3.0/models/atlas: drc_robot.pdf
> Only in drcsim-1.3.0/models/atlas/meshes: l_clav.dae.orig
> Only in drcsim-1.3.0/models/atlas/meshes: r_clav.dae.orig
> Only in drcsim-1.3.0/models/atlas: model.sdf.orig
> Only in drcsim-1.3.0/models/atlas: model.sdf.rej
> Only in drcsim-1.3.0/models: drc_robot.gv
> Only in drcsim-1.3.0/models: drc_robot.sdf
> Only in drcsim-1.3.0/models/drc_terrain/materials/textures:
> dirt_diffusespecular.png
> Only in drcsim-1.3.0/models/drc_terrain/materials/textures: dirt_normal.png
> Only in drcsim-1.3.0/models/drc_terrain/materials/textures:
> fungus_diffusespecular.png
> Only in drcsim-1.3.0/models/drc_terrain/materials/textures:
> fungus_normal.png
> Only in drcsim-1.3.0/models/drc_terrain/materials/textures:
> grass_diffusespecular.png
> Only in drcsim-1.3.0/models/drc_terrain/materials/textures:
> grass_normal.png
> Only in drcsim-1.3.0/models: low_poly_golf_cart.model-1.0
> Only in drcsim-1.3.0/models: pr2.model
> Only in drcsim-1.3.0/plugins/ros: .DRCRobotPlugin.cc.swo
> Only in drcsim-1.3.0/plugins/ros: gazebo_ros_api_plugin.cpp.orig
> Only in drcsim-1.3.0/plugins/ros: gazebo_ros_api_plugin.h.orig
> Only in drcsim-1.3.0/plugins/ros: gazebo_ros_bumper.cpp
> Only in drcsim-1.3.0/plugins/ros: gazebo_ros_bumper.h
> Only in drcsim-1.3.0/plugins/ros: MultiSenseSLPlugin.cpp.1
> Only in drcsim-1.3.0/plugins/ros: MultiSenseSLPlugin.h.1
> Only in drcsim-1.3.0/plugins/ros: test.cpp
> Only in drcsim-1.3.0/ros/atlas_utils/cmake: bdip-config.cmake
> Only in drcsim-1.3.0/ros/atlas_utils/cmake: pkgconfig
> Only in drcsim-1.3.0/ros/atlas_utils: drc_robot.sdf
> Only in drcsim-1.3.0/ros/atlas_utils: model.urdf
> Only in drcsim-1.3.0/ros/atlas_utils/raw: my_gripper.sdf
> Only in drcsim-1.3.0/ros/atlas_utils: test.launch
> Only in drcsim-1.3.0/ros/atlas_utils/urdf: drc_robot.urdf.orig
> Only in drcsim-1.3.0/ros/atlas_utils/urdf: drc_robot.urdf.rej
> Only in drcsim-1.3.0/ros/simple_trajectory: bin
> Only in drcsim-1.3.0: test.c
> Only in drcsim-1.3.0: tutorials
> Only in drcsim-1.3.0/worlds: CMakeLists.txt.orig
> Only in drcsim-1.3.0/worlds: drc_robot.world.orig
> Only in drcsim-1.3.0/worlds: .drc_robot.world.swo
> Only in drcsim-1.3.0/worlds: empty.world
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-release/attachments/20130103/28a9a564/attachment-0008.html>

More information about the Ros-release mailing list