Ask Your Question
4

Rebuilding workspace after kinetic update?

asked 2018-09-11 15:24:20 -0600

NotABot gravatar image

updated 2018-09-11 16:23:24 -0600

ahendrix gravatar image

Hi there. After the latest update I'm encountering various breakages and processes dying on startup. For example a Time is out of dual 32-bit range error. Should my workspace and ROS nodes etc be built after a large update like this?

edit retag flag offensive close merge delete

Comments

Probably. It would help to know if you're just upgrading packages within Kinetic, or upgrading from an older version of ROS (Indigo, Jade, etc) to Kinetic.

ahendrix gravatar imageahendrix ( 2018-09-11 16:24:36 -0600 )edit

From an older version of Kinetic. Is it possible to roll back to previous versions of the packages? Or reinstall without that update?

NotABot gravatar imageNotABot ( 2018-09-11 16:33:33 -0600 )edit

We've also been having issues with a kinetic build that seems to have been released approx 4 days ago. We build all our ros into docker containers, I have a docker from 5 days ago that launches our stack fine, the one from 4 days ago fails. Half of the nodes die on launch without any useful logs.

lstelzner gravatar imagelstelzner ( 2018-09-11 19:58:36 -0600 )edit

3 Answers

Sort by ยป oldest newest most voted
3

answered 2018-09-11 20:53:52 -0600

ahendrix gravatar image

There was a release of package updates for Kinetic a few days ago: https://discourse.ros.org/t/new-packa... . It looks like that included releases of lots of packages.

It sounds like you're seeing either an ABI compatibility issue, or a bug introduced by one of the changes in one of the packages that was updated. In general ROS strives to maintain backward compatibility with these updates so that you don't need to recompile when you update packages, but sometimes the packages maintainers make mistakes, or it's just not possible.

If this is an ABI compatibility issue or a new bug, it should be reported upstream immediately so that the maintainers can decide how best to handle it. If you're not sure which package or stack to report this issue on, I suggest you update your question with the exact error message that you're seeing, or ask a new question that includes the exact error message.

edit flag offensive delete link more

Comments

5

This was most likely an ABI breakage: we've had several workspaces 'break' after the latest sync. All of those fixed by updating all ROS pkgs (not just a few of the outstanding updates) and then rebuilding the workspace.

Rebuilding after a apt update is always recommended.

gvdhoorn gravatar imagegvdhoorn ( 2018-09-12 01:53:54 -0600 )edit
2

answered 2018-09-12 12:21:21 -0600

athackst gravatar image

To answer the OP question: Yes. It looks like you need to recompile.

We were seeing a (related) issue with our docker builds, however we _were_ compiling our code in the image. Our problem looks like it is from the released ros:kinetic docker image not having the latest update in it (despite being updated 6 days ago). So the packages we were installing were built against a newer (non-backward compatible) versions of base packages than were installed on the image (_and_ those packages didn't call out needing the newer base packages).

Needed action from OSRF: Update the ros:kinetic docker image

I assume the docker image is built inside the build farm and triggered by the release, so I'm a little surprised that it is behind. I think something needs to be updated on the build farm to prevent this from happening again.

edit flag offensive delete link more
0

answered 2018-09-12 03:23:20 -0600

updated 2018-09-12 03:45:17 -0600

gvdhoorn gravatar image

Does the latest release include a rebuilt librostime.so? Here's a partial backtrace from a robot_state_publisher that after the latest update now seg faults:

Thread 1 "state_publisher" received signal SIGSEGV, Segmentation fault.
0x00007ffff6b385ea in ros::TimeBase<ros::Time, ros::Duration>::operator+(ros::Duration const&) const () from /opt/ros/kinetic/lib/librostime.so<br>
(gdb) bt<br>
\#0  0x00007ffff6b385ea in ros::TimeBase<ros::Time, ros::Duration>::operator+(ros::Duration const&) const () from /opt/ros/kinetic/lib/librostime.so<br>
\#1  0x0000000000409af4 in robot_state_publisher::JointStateListener::callbackJointState(boost::shared_ptr<sensor_msgs::JointState_<std::allocator<void> > const> const&) ()

Looking at rostime the last commit to rostime/include/ros/duration.h looks like it could be the culprit if the library-side and the caller were not both rebuilt.

edit flag offensive delete link more

Comments

Unfortunately Askbot doesn't really lend itself to this kind of interaction (ie: posting answers with more questions), but I've just commented on ros/roscpp_core#90 which seems to have introduced the changes you refer to.

gvdhoorn gravatar imagegvdhoorn ( 2018-09-12 03:46:10 -0600 )edit

Just realised #90 is not related, as that PR wasn't merged in version 0.6.11, which is the current version of roscpp_core released into Kinetic (see status page).

gvdhoorn gravatar imagegvdhoorn ( 2018-09-12 03:48:30 -0600 )edit

Right the change is not in the released version of roscpp, but are other packages, like robot_state_publisher, compiling against the released roscpp or the head of the kinetic-devel branch?

ron.goldman gravatar imageron.goldman ( 2018-09-12 11:08:05 -0600 )edit
1

Builds of released pkgs are against other versions of released pkgs. Never against head of anything afaik.

gvdhoorn gravatar imagegvdhoorn ( 2018-09-12 11:12:55 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-09-11 15:24:20 -0600

Seen: 856 times

Last updated: Sep 12 '18