I found out that our gnash::font class was storing texture_glyph *values* into a std::vector, while texture_glyph is a ref_counted (thus GcManaged) class.
Now, this is unsafe (and corrupts memory in the GC case) in that std::vector will destroy the values after copying them somewhere else on resize. GC-managed instances should *never* be deleted by anyone else that the GC. Also, GC-managed instances should *never* be allocated on the stack ! For texture_glyph class, this happens often, so I'm debating wheter that class really needs to be a ref_counted (thus GcManaged) object at all. Currently, it seems that no parts of the code are storing texture_glyph into intrusive_ptr, and so the code doesn't blow up that much. If we used a similar 'wrapping' for registration into the GC it wouldn't be a big problem for GC model either. Basically, the change would be that GcResource instances would not be *automatically* (by GcResource ctor) registered to the GC, but the registration would be offered by a pretty simple and dumb gc_ptr<> templated class. Storing a GcResource pointer into a gc_ptr<> class could register that pointer into the GC for you. Mapping a 'smart_ptr' macro to either 'intrusive_ptr' (for the RC case) or 'gc_ptr' (for the GC) case would likely give us the same abstraction for both models, which is: use 'smart_ptr' when not willing to have full control over lifetime, don't use it to expliclty manage it (and possibly allocate on the stack too) --strk; () ASCII Ribbon Campaign /\ Keep it simple! _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
