Hello Gerrit,
we are having one more problem with our app. The setup is like this:
editor:
Aspect 0: multiple threads implementing the editor logic
Aspect 1: one thread sending changes to our cave
cave:
Aspect 0: one thread rendering
Aspect 1: one thread receiving changes
The cave part crashes under certain (reproducible) circumstances in
AttachmentContainer::resolveLinks on the unlinkParent call. It looks
like the attachment is already gone.
Looking through the ref counting for the attachments I've noticed that
there is the isMTLocal() check and depending on that a recorded or
unrecorded ref change is made. I don't think that is correct, since the
attachment map essentially behaves like a field and we never record the
ref count changes made by a field, so I believe these should all be
unrecorded.
Indeed the attached patch fixes our problem. What do you think?
The isMTLocal() change was done in r1357, maybe the commit message
"record attachment refcounts if container is a bundle to fix multi
aspect mem leak" allows you to recall what the problem addressed by it was?
Thanks & Cheers,
Carsten
diff --git a/Source/Base/FieldContainer/Base/OSGAttachmentContainer.cpp b/Source/Base/FieldContainer/Base/OSGAttachmentContainer.cpp
index 65a61b4..9f35db0 100644
--- a/Source/Base/FieldContainer/Base/OSGAttachmentContainer.cpp
+++ b/Source/Base/FieldContainer/Base/OSGAttachmentContainer.cpp
@@ -179,14 +179,7 @@ void AttachmentContainer::addAttachment(
key = (UInt32 (pAttachment->getGroupId()) << 16) | binding;
- if(this->isMTLocal())
- {
- pAttachment->addReferenceUnrecorded();
- }
- else
- {
- pAttachment->addReferenceRecorded();
- }
+ pAttachment->addReferenceUnrecorded();
pAttachment->linkParent(this,
AttachmentsFieldId,
@@ -201,14 +194,7 @@ void AttachmentContainer::addAttachment(
(*fcI).second->unlinkParent(this,
Attachment::ParentsFieldId);
- if(this->isMTLocal())
- {
- (*fcI).second->subReferenceUnrecorded();
- }
- else
- {
- (*fcI).second->subReferenceRecorded();
- }
+ (*fcI).second->subReferenceUnrecorded();
(*fcI).second = pAttachment;
}
@@ -252,14 +238,7 @@ void AttachmentContainer::subAttachment(
(*fcI).second->unlinkParent(this,
Attachment::ParentsFieldId);
- if(this->isMTLocal())
- {
- (*fcI).second->subReferenceUnrecorded();
- }
- else
- {
- (*fcI).second->subReferenceRecorded();
- }
+ (*fcI).second->subReferenceUnrecorded();
_sfAttachments.getValue().erase(fcI);
}
@@ -360,14 +339,8 @@ void AttachmentContainer::execSync(
while(fcI != fcE)
{
- if(this->isMTLocal())
- {
- (*fcI).second->subReferenceUnrecorded();
- }
- else
- {
- (*fcI).second->subReferenceRecorded();
- }
+ Thread::getCurrentChangeList()->addDelayedSubRef<
+ UnrecordedRefCountPolicy>((*fcI).second);
++fcI;
}
@@ -389,15 +362,7 @@ void AttachmentContainer::resolveLinks(void)
(*fcI).second->unlinkParent(this,
Attachment::ParentsFieldId);
-
- if(this->isMTLocal())
- {
- (*fcI).second->subReferenceUnrecorded();
- }
- else
- {
- (*fcI).second->subReferenceRecorded();
- }
+ (*fcI).second->subReferenceUnrecorded();
++fcI;
}
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core