gazebo 7.8 crash more visible or more common

[osrf-migration]

Original report (archived issue) by Jeremy White (Bitbucket: knitfoo).

---

A gazebo server crash, which has been one of the common startup failures (but perhaps only 1 in 10 or even less than that), now seems to happen more often.

Notably, it seems as though when we give it a checkpoint move instruction, and we're at the point of reharness, we seems to risk getting it again. Perhaps nicely, this failure seems to come with more informaton. I get the following on the terminal:

#!c++

[libprotobuf ERROR google/protobuf/message_lite.cc:123] Can't parse message of type "gazebo.msgs.Packet" because it is missing required fields: stamp, type, serialized_data
Master Unknown message type[] From[44894]
[libprotobuf ERROR google/protobuf/message_lite.cc:123] Can't parse message of type "gazebo.msgs.Packet" because it is missing required fields: stamp, type, serialized_data
Master Unknown message type[] From[44894]
gzserver: /usr/include/boost/smart_ptr/shared_ptr.hpp:653: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = gazebo::transport::Publisher; typename boost::detail::sp_member_access<T>::type = gazebo::transport::Publisher*]: Assertion `px != 0' failed.
Aborted (core dumped)
[gazebo-6] process has died [pid 22627, exit code 134, cmd /opt/ros/indigo/lib/gazebo_ros/gzserver --verbose -e ode -r /home/jwhite/w/srcsim/worlds/final_2.world __name:=gazebo __log:=/home/high/.ros/log/d7154fac-4930-11e7-a564-fcf8ae5ce333/gazebo-6.log].
log file: /home/high/.ros/log/d7154fac-4930-11e7-a564-fcf8ae5ce333/gazebo-6*.log

The can't parse message errors are familiar to me, and the gzserver crash is familiar as well. The assertion failure is new.

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

@knitfoo , if you had a chance, you could roslaunch with debug:=true, which runs Gazebo through gdb (if it is installed), and get a backtrace.

[osrf-migration]

Original comment by Vinayak Jagtap (Bitbucket: vinayak_jagtap).

---

@chapulina Thanks for that info. I didn't know it was that easy. I'll just default it to true as I keep seeing these errors often.

[osrf-migration]

Original comment by Jeremy White (Bitbucket: knitfoo).

---

Huh. I thought I was always running with debug:=true; I must have lost that somewhere along the way. /me blushes. Putting it back in now...

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

• set component to "world"

[osrf-migration]

Original comment by Jeremy White (Bitbucket: knitfoo).

---

Urk. Very first run on r771 got this simply walking out of the finish box. Had debug off, because I wanted to test production circumstances.

[osrf-migration]

Original comment by Jeremy White (Bitbucket: knitfoo).

---

Okay, other runs on r771 are okay; I'll keep an eye out. Hopefully no escalation of this one from that raft of changes.

[osrf-migration]

Original comment by Erica Tiberia (Bitbucket: T_AL).

---

I'm noticing consistent crashes in the hab after reharness - log says robot is being lowered, detached etc but she is just hanging there.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

@T_AL if it is stuck with harness in state 4 (as in #210 or this problem with pelvis height), I have had some success by sending new pelvis height commands, or just manually detaching (at your own risk) if both feet are on the ground but the weight distribution is uneven, causing the detachment logic not to trigger:

rostopic pub -1 /valkyrie/harness/detach std_msgs/Bool true