"gzserver" received signal SIGSEGV, Segmentation fault
Thread 198 "gzserver" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f933bbfe700 (LWP 25829)] 0x00007f95b7a81b74 in std::_atomicbase
::load ( _m=std::memoryorderseqcst, this=0x7f951c045d90) at /usr/include/c++/7/bits/atomicbase.h:396 396 return _atomicloadn(&Mi, __m); (gdb) bt 0 0x00007f95b7a81b74 in std::atomicbase
::load(std::memory order) const (m=std::memoryorderseq_cst, this=0x7f951c045d90)at /usr/include/c++/7/bits/atomic_base.h:396
1 0x00007f95b7a81b74 in std::atomic
::operator bool() const (this=0x7f951c045d90) at /usr/include/c++/7/atomic:86 2 0x00007f95b7a81b74 in gazebo::event::EventT
::Signalgazebo::common::UpdateInfo(gazebo::common::UpdateInfo const&) (_p=..., this= ) at /home/***/gazebo-9.0.0/gazebo/common/Event.hh:291
3 0x00007f95b7a81b74 in gazebo::event::EventT
::operator()gazebo::common::UpdateInfo(gazebo::common::UpdateInfo const&) (_p=..., this= ) at /home/***/gazebo-9.0.0/gazebo/common/Event.hh:128
4 0x00007f95b7a81b74 in gazebo::physics::World::Update() (this=this@entry=0x55fc0b613190) at /home/***/gazebo-9.0.0/gazebo/physics/World.cc:767
5 0x00007f95b7a8cc6b in gazebo::physics::World::Step() (this=this@entry=0x55fc0b613190) at /home/***/gazebo-9.0.0/gazebo/physics/World.cc:696
6 0x00007f95b7a8d11d in gazebo::physics::World::RunLoop() (this=0x55fc0b613190) at /home/***/gazebo-9.0.0/gazebo/physics/World.cc:505
7 0x00007f95b89686df in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
8 0x00007f95b7da96db in start_thread (arg=0x7f933bbfe700)
at pthread_create.c:463
9 0x00007f95b83c371f in clone ()
---Type
to continue, or q to quit--- at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Why?
Asked by KASUYASU on 2021-01-08 07:28:05 UTC
Answers
This is NOT the true answer, but I rewrite the code of 'Event.hh' like
public: template< typename P >
__attribute__((optimize("O0"))) void Signal(const P &_p)
{
std::lock_guard<std::mutex> lock(this->mutex);
this->Cleanup();
this->SetSignaled(true);
for ( auto i = this->connections.begin(); i != this->connections.end(); ++i )
{
bool *b = nullptr;
b = &i->second->on;
if (b == nullptr) {
ConnectionCount();
b = &i->second->on;
if (b == nullptr) {
std::cout << "Can't get pointer &i->second->on !!\n";
continue;
}
}
std::function<T> (*func);
func = &i->second->callback;
if (*b == true)
(*func)(_p);
}
}
and add the function 'ConnectionCount()' to 'Cleanup()' like
unsigned int EventT<T>::Cleanup()
{
std::lock_guard<std::mutex> lock(this->mutex_2);
// Remove all queue connections.
for (auto &conn : this->connectionsToRemove) {
this->connections.erase(conn);
ConnectionCount();
}
this->connectionsToRemove.clear();
return ConnectionCount();
}
Maybe , there exists some bugs in the std::map, however above tampering reduces the segmentation fault dramatically.
Kazu
Asked by KASUYASU on 2021-01-19 05:28:51 UTC
Comments
From the view point of source code, maybe, the developers of this project do not have the correct knowledge of thread programming, mutex, and atomic memory access. Of course, you are free to use or not use such products.
Kazu
Asked by KASUYASU on 2021-02-03 05:49:56 UTC
Comments
Hello,
can you provide more details ?
Is this happening when you launch ... ? - A demo (which one) - your own world - your own plugin/code
This trace is not enough to understand what is going on.
Asked by ahcorde on 2021-01-13 06:00:30 UTC
Hi,
I've only downloaded the GitHub's project
https://github.com/PierreExeter/jaco-gym
installed the several packages, and evoked
roslaunch kinova_gazebo robot_launch_render.launch kinova_robotType:=j2n6s300
and
python3 scripts/1_train_ppo2.py
. After the evoking, gzserver makes the "segmentation fault" sporadically.
I'm using Ubuntu18.04, ROS melodic, Python 3.6.9, gym-0.18.0 and gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0.
It seems to me that stack destruction is occurring.
Kazu
Asked by KASUYASU on 2021-01-14 02:46:11 UTC