Steve Fink [:sfink] [:s:] Reporter
	Description • 12 years ago

Over in bug 720949, I discovered that you can do

  obj = NewBuiltinClassInstance(protoClass);
  empty = EmptyShape::getInitialShape(anotherClass);
  obj->setLastPropertyInfallible(empty);

and screw things up. Specifically, protoClass has no finalizer, and so results in a background-finalizable object. Mutating the object via setLastPropertyInfallible switches it to anotherClass, which *does* have a finalizer, but it'll never get called because the finalization kind is an immutable property (it's derived from the storage location, so it really can't be changed.)

Should setLastPropertyInfallible assert if the finalization kind changes? Or is there a better place for it? Or am I misunderstanding something?

	Bill McCloskey [inactive unless it's an emergency] (:billm)
	Comment 1 • 12 years ago

It would be a good assertion to add. However, I was under the impression that we never change the class of an object except for array slowification.

	Steve Fink [:sfink] [:s:] Reporter
	Comment 2 • 12 years ago

(In reply to Bill McCloskey (:billm) from comment #1)
> It would be a good assertion to add. However, I was under the impression
> that we never change the class of an object except for array slowification.

Could be true. The typed array object creation code was clearly cargo-culted from the array creation code, and brought over the class changing stuff for its normal object creation path. (I think the array code used to do this too, though the current version looks more sane.) I hope to remove that as part of getting bug 720949, but the finalizeKind-changing stuff still seems like a nasty footgun to leave lying around.

	Steve Fink [:sfink] [:s:] Reporter
	Comment 3 • 12 years ago

I briefly attempted this, but getting access to the necessary data at the point you'd want the assertion is hard.