[Ros-release] ABI compatibility
Brian Gerkey
gerkey at osrfoundation.org
Thu Jan 3 20:54:08 UTC 2013
hi Vijay,
Thanks for the reply, and don't feel bad. It didn't cause us that
much pain (thanks to Hugo's quick thinking as to the cause).
Also, to be honest, I wasn't aware that REP 9 is in effect. I recall
Josh writing it ages ago, but didn't know that we'd adopted it as a
policy. So I wouldn't have thought twice about introducing
ABI-breaking changes myself.
Of course, REP 9 is a good policy and we should all be following it.
It probably hasn't come up much in the past because if you only
release your code using the ROS release system, then your debs will
all be strictly version-locked and you won't see this problem. But
now, people (like us) are starting to release stuff in other ways
while depending on ROS debs. That's a good thing, and is something
that we should work to support.
And I agree that reverting the change in pr2_mechanism doesn't make
sense now; our problem is fixed.
brian.
p.s. For those not subscribed to the ros-release@ list, be sure to
check out Rich's reply, with detailed analysis and pointers to tools:
https://code.ros.org/lurker/message/20130103.202349.f8be05b0.en.html
On Thu, Jan 3, 2013 at 12:30 PM, Vijay Pradeep <vijay at hidof.com> wrote:
> 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
> help.
>
> Vijay Pradeep
> hiDOF, Inc.
> Co-Founder
>
> 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 @@
>>
>> set (DRC_SIM_MAJOR_VERSION 1)
>> set (DRC_SIM_MINOR_VERSION 3)
>> -set (DRC_SIM_PATCH_VERSION 0)
>> +set (DRC_SIM_PATCH_VERSION 1)
>> set (DRC_SIM_VERSION ${DRC_SIM_MAJOR_VERSION}.${DRC_SIM_MINOR_VERSION})
>> set (DRC_SIM_VERSION_FULL
>>
>> ${DRC_SIM_MAJOR_VERSION}.${DRC_SIM_MINOR_VERSION}.${DRC_SIM_PATCH_VERSION})
>> 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
>
>
More information about the Ros-release
mailing list