Open Bug 1332730 Opened 5 years ago Updated 5 years ago
Object interior pointers with hazard analysis
Cloned from bug 1296640. Comments repeated below: (In reply to Jon Coppeard (:jonco) from comment #10) > > But there has to be a way, using the static analysis, to detect this kind of issues more generally, right? > > Yep, the hazard analysis should be able to catch this. I think you need to > annotate your Elem types with JS_HAZ_GC_INVALIDATED, but Steve will know > more. Yes, we should totally expose these to the analysis. The usual difficulty is that you have to have a C++ type to distinguish a pointer to GC memory vs pointers to anything else. You kind of have that here, with Elem. Except that the pointer that would get invalidated is the Elem*, not the Elem. So you'd sort of like to mark the type Elem* as either JS_HAZ_GC_INVALIDATED or JS_HAZ_GC_POINTER (depending on whether you want to consider interior pointers to be GC pointers or not; I could argue either way, but the analysis doesn't care.) But you can only annotate bare C++ types, not pointers to them or whatever. So I think you'd need to tell a little white lie and claim that Elem is a JS_HAZ_GC_THING. That will make a pointer to an Elem be considered a GC pointers that could be invalidated on GC. But Elem is not a real type, it's a typedef to V::Elem, which is a template parameter, and V::Elem is generally something like int8_t. The compiler sees through typedefs for the most part, so this isn't going to work; we'd be declaring 'char' to be a GC type. :( Maybe I'll see if we can make TypedObjectMemory return some sort of wrapper type instead of a plain Elem*, though I'm skeptical that we won't need it to degrade to a plain pointer immediately. Or perhaps the big hammer -- requiring TypedObjectMemory to be given an AutoAssertOnGC&, and fixing up all callers. This is the same sort of interior pointer pain we have with pointers to JSString contents.
You need to log in before you can comment on or make changes to this bug.