Segmentation Fault in Garbage Collection
MirkoWaechter
Member Mirko WaechterOrganization: University of KarlsruheProject: ArmarX Robot Framework ✭
in Help Center
Hello,
we have occasionally seg faults in the garbage collection of Ice:
The structure of the classes that are involved is:
Entity has a list of EntityAttributes and EntityWrappers.
EntityWrapper has an IceHandle to the Entity it belongs to (so a cycle and a case for the Garbage Collection).
When Cloning Entities, I first create an empty instance, assign it to a Handle and then copy the values inside, so that the ref count is > 1 and the GC cannot collect it during copying of the EntityWrappers.
The slice interface definitions (without functions) look like this:
I dont really understand why the garbage collection is doing something with the EntityAttributeBase, since there cannot be any cycle with this class.
All instances of any of these types are stored in IceHandles.
So, are there any known bugs with the GC?
Is the instance not locked while examined by the GC?
Why does it examine the EntityAttributeBase, although this class cannot have any cycles?
We are using Ice 3.4.2, Ubuntu 12.04 and gcc 4.6.
thanks
Mirko
we have occasionally seg faults in the garbage collection of Ice:
Error: Segmentation Fault
Backtrace:
Backtrace:
1 0x7fe0ba2c1b39 armarx::Application::HandlerFault(int) + 185
2 0x7fe0b66b9150 /lib/x86_64-linux-gnu/libc.so.6(+0x36150) [0x7fe0b66b9150]
3 0x7fe0b8cb3502 memoryx::EntityAttributeBase::__gcReachable(std::map<IceInternal::GCShared*, int, std::less<IceInternal::GCShared*>, std::allocator<std::pair<IceInternal::GCShared* const, int> > >&) const + 178
4 0x7fe0bb2ceb3e IceInternal::GC::collectGarbage() + 478
5 0x7fe0bb2cf10e IceInternal::GC::run() + 446
6 0x7fe0baf6d96f /usr/lib/libIceUtil.so.34(+0x2f96f) [0x7fe0baf6d96f]
7 0x7fe0b7c94e9a /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x7fe0b7c94e9a]
8 0x7fe0b677638d clone + 109
The structure of the classes that are involved is:
Entity has a list of EntityAttributes and EntityWrappers.
EntityWrapper has an IceHandle to the Entity it belongs to (so a cycle and a case for the Garbage Collection).
When Cloning Entities, I first create an empty instance, assign it to a Handle and then copy the values inside, so that the ref count is > 1 and the GC cannot collect it during copying of the EntityWrappers.
The slice interface definitions (without functions) look like this:
interface Serializable
{
["cpp:const"]
void serialize(ObjectSerializerBase serializer);
void deserialize(ObjectSerializerBase serializer);
};
class AttributeBase implements armarx::Serializable
{
["protected"]
string name;
};
class EntityAttributeBase extends AttributeBase
{
["protected"]
AttributeElementList values;
};
dictionary<string, EntityAttributeBase> AttributeMap;
class EntityBase implements armarx::Serializable
{
["protected"]
string id;
["protected"]
string name;
["protected"]
AttributeMap attributes;
["protected"]
[B]AbstractEntityWrapperBaseList wrappers;[/B] // <- causes cycle
};
class AbstractEntityWrapperBase
{
["protected"]
[B]EntityBase entity;[/B]// <- causes cycle
};
I dont really understand why the garbage collection is doing something with the EntityAttributeBase, since there cannot be any cycle with this class.
All instances of any of these types are stored in IceHandles.
So, are there any known bugs with the GC?
Is the instance not locked while examined by the GC?
Why does it examine the EntityAttributeBase, although this class cannot have any cycles?
We are using Ice 3.4.2, Ubuntu 12.04 and gcc 4.6.
thanks
Mirko
0
Comments
The mutex of the GC is inaccesible.
How is this supposed to work?
cheers
Mirko
It is as suspected. The GC is running while clearing the member container.
The stacktraces of both threads:
It is the same object, on which both threads are currently operating.
As you've discovered the garbage collection has thread-safety issues. We have reworked its implementation with the upcoming Ice 3.6. There's no more garbage collection thread. See Garbage Collection Improvements for the details.
Cheers,
Benoit.
Is there anyway to get the mutex of the garbage collection?
Sorry, no, it's not possible to access the mutex of the garbage collection.
You would need to patch Ice to provide access to it through the IceInternal::GCShared interface (defined in cpp/include/Ice/GCShared.h and implemented in cpp/src/Ice/GC.cpp).
The best would be to try out 3.6b. The final release is due in few weeks.
Cheers,
Benoit.