core: Fix "Failed to get Object" panics #18046
Conversation
evilpie
added
A-core
torokati44
force-pushed
the
amf_fixes
branch
from
ff75f1e
to
dc59d83
Compare
|
Since the act of merging ruffle-rs/rust-flash-lso#68 changed its HEAD hash (and there were some changes added to it even before the merge), I amended this branch accordingly. While at it, I also squashed a few "fixup" type commits into the original commits they fix, for cleaner commit history. I hope you don't mind, @CUB3D. |
|
|
||
| // Swap in the actual values | ||
| obj.as_vector_storage_mut(activation.context.gc_context) | ||
| .unwrap() |
There was a problem hiding this comment.
nit: I believe we generally prefer expect, with a meaningful message.
There was a problem hiding this comment.
Actually, I don't think it's worth blocking on this, I see no way for this to fail, obj is created locally, right above this line.
There was a problem hiding this comment.
If you are also okay with leaving this as is, @Dinnerbone, I'd say go for the merge.
| *occupied_count = new_occupied_count; | ||
| *storage = new_storage; | ||
| } | ||
| ArrayStorage::Sparse { .. } => {} |
There was a problem hiding this comment.
Can this panic, just to ensure that it doesn't accidentally get called on a Sparse array?
This constitues the ruffle-side changes of ruffle-rs/rust-flash-lso#67 and ruffle-rs/rust-flash-lso#68.
This fixes the following (previously would panic on load):
#17902 - loads
#17709 - loads
#13748 - loads
#10520 - loads
This prevents panics on the following:
#17782 - (and possible dupe #17336 )
Now errors with "Property uploadFromBitmapData not found on flash.display3D.textures.RectangleTexture and there is no default value."
#14329
Fails to load past 54%, some URL load failures might be related
#10174
Same as 17782 above
These are not fixed, but one possible underlying issue is that a new
AMF3Decoderis created for each call toByteArray.readObjectwhich could result in missing references that are replaced withUndefinedwhen an element references a prior value in the stream. In the simple case, we could just cache theAMF3Decoderin theByteArrayobject, but this won't handle more complex cases where theByteArrays position is changed, so I'm leaving this for future work.Update: I'm actually unsure if the above guess is true anymore, a missing change progressed the above and removed the invalid reference warnings but it still seems odd.