516379 - Allocation in destructor can lead to OOM abort; different destructor semantics desired

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Garbage Collection (mmGC), enhancement, P3)

Description

[vsaripal]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: 

When GC is collecting in the memoryStatusChange (GCHeap is already in kMemReserve state), ClearWeakRef would result in GCHashTable allocating more memory. This would cause the GCHeap to Abort and a longjmp would result in invalid GC state. ( ZCT would still be in slowState). The main problem here is a Abort in GC's Collection.

Reproducible: Always




If i try to catch the longjmp at the GC::Sweep level and rethrow it after calling zct.EndCollecting(), it works fine. Contact me for StackTraces etc

Comment 1

[vsaripal]

Also, the weakref, that was to be cleared will not be cleared.

Comment 2

[Tommy Reilly]

Hmm, we pass !collecting to remove to tell it to not to rehash, is that not working for some reason?

Comment 3

[vsaripal]

hmm, our product is not updated with latest tamarin source. looks like that would clear the "grow" issue. But the problem still exists, as allocations could happen in Destructors.

Comment 4

[Lars T Hansen]

(In reply to comment #3)
> hmm, our product is not updated with latest tamarin source. looks like that
> would clear the "grow" issue. But the problem still exists, as allocations
> could happen in Destructors.

Allocations in destructors that are run as a result of OOM garbage collections are dangerous.  The main fix for that is to reduce our reliance on the current destructor semantics and run destructors after GC.  We can implement that by separating reference-counting-only destructors from other destructors and run the former synchronously during ZCT reaping / GC, and the latter following GC.  Either way this is out of scope at the moment, so I will downgrade this bug accordingly.

Comment 5

[Tommy Reilly]

De-coupling from OOM implementation master bug since this has morphed into a request to change how destructors are executed.

Comment 6

[Lars T Hansen]

Fixes to finalization semantics are a hot item for upcoming work.

Comment 7

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.