Gerrit Voss wrote: > Hi, > > > On Tue, 2007-04-24 at 16:15 -0500, [EMAIL PROTECTED] wrote: >> Fix for an especially insidious bug that led to random seg faults and memory >> protection crashes in the ContainerChangeEntry processing. >> >> The cause is a bit complex, but the basic idea is this. >> >> - ContainerChangeEntries are stored in a pool in the ChangeList class and >> reused. >> - When an entry is reused the clear() method is called to reset it to a >> "good" state. >> - One of the things stored in the ContainerChangeEntry was a reference to >> the uncommittedChanges flags inside the relevant field container >> - This value was never cleared because it was a reference >> >> In some cases what would happen is: >> - A ContainerChangeEntry would be allocated to point at a fc fcA with >> uncommitedFlags set to point at fcA >> - fcA would be deallocated and the change entry put back into the pool >> - A new change would happen for a new fc fcB that would not require setting >> the uncommitedFlags reference >> - When that ContainerChangeEntry was processed it would still reference the >> uncommitedFlags for fcA and thus reference invalid memory >> - When this variable was used, poof, crash, bang, badness. > > I understand the problem, what I would be interested in would be how did > you manage to trigger it because that seems to be the real problem. > > Especially how did you manage to get the following: > > '- A new change would happen for a new fc fcB that would not require > setting the uncommitedFlags reference' >
I tried to reproduce it in a test case but I was never able to do it. All I know for sure is that several magically little random crashes have now been removed from our application. I don't know the code as well as you though, so maybe you can think up a test case that could force it. The best idea I had was to allocate several field containers, deallocate one of them, and then start inc/dec the reference count of all the others. Like I said though, that didn't work. I am just happy that the code is more stable for us now. :) -Allen > > A changed entry with an invalid flag reference should have never been > processed in a way that the invalid reference is touched. > > The only time I found this to happen was during ChangeList::dump. > > So the 'real' bug is still out there. > > > gerrit > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
