Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
don't destroy synchro in a simcall, this drives the JVM nuts
authorMartin Quinson <martin.quinson@loria.fr>
Tue, 2 Feb 2016 22:08:24 +0000 (23:08 +0100)
committerMartin Quinson <martin.quinson@loria.fr>
Tue, 2 Feb 2016 22:12:25 +0000 (23:12 +0100)
commit972791c2823bfc1694d827b1e943eb725847e2d8
tree101e092357e19fc4ac7319b550d1d6145a0e5932
parent0d237810a7a374c6e9077dfff3c9c06db0622e1e
don't destroy synchro in a simcall, this drives the JVM nuts

The destroy is called from the GC thread when running in the JVM. And
that thread is obviously not a simix thread, so the simcall mechanism
won't work properly.

I tried to make it a simix thread when I see it (ie, when
JavaThreadFactory::self() is about to return NULL), but it leads to
further complications, such as the following error message:

  Can't extend stack to 0x22f35958 during signal delivery for thread 9:
  no stack segment

Oha. That hurts. I've no idea of why that thread has no stack, and I
think I don't want to know. Actually, it makes no sense to delete the
synchronization objects from a simcall only. Why would this need to be
linearized in a reproductible way? So, delete these objects directly,
and everything works well.

That bug was reported in:
https://gforge.inria.fr/tracker/index.php?func=detail&aid=19893&group_id=12&atid=165
examples/msg/actions/actions.c
include/simgrid/simix.h
src/msg/msg_synchro.cpp
src/simix/libsmx.cpp
src/simix/popping_accessors.h
src/simix/popping_bodies.cpp
src/simix/popping_enum.h
src/simix/popping_generated.cpp
src/simix/simcalls.in
src/simix/smx_synchro_private.h
src/xbt/xbt_os_synchro.c