1252511 - "Assertion failure: uint32_t(LittleEndian::readUint64(point) >> 32) < SCTAG_TRANSFER_MAP_HEADER" with DOM MessageChannel

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jesse Ruderman]

Attachment: testcase

Assertion failure: uint32_t(LittleEndian::readUint64(point) >> 32) < SCTAG_TRANSFER_MAP_HEADER, at js/src/vm/StructuredClone.cpp:1352

Comment 1

[Jesse Ruderman]

Attachment: stack

Comment 2

[Andrea Marchesini [:baku]]

Steve, this doesn't seem a bug in MessagePort/MessageChannel. Can you take a look?

Comment 3

[Andrew McCreight [:mccr8]]

ni? sfink per comment 2.

Comment 4

[Andrew McCreight [:mccr8]]

I'm moving this over to Javascript Engine because baku thinks it isn't in DOM message stuff.

Comment 5

[Andrew McCreight [:mccr8]]

Any updates?

Comment 6

[Steve Fink [:sfink] [:s:]]

Sorry for the long delay. Turned out to be pretty trivial, just a faulty assertion. It was sort of doing an indirect check of the number of transferables between the beginning and end of the cloning process, but it was assuming that all valid type tags were less than the transferable tags, which is not the case -- it is correct for all builtin types, but not for callback-provided user types.

Comment 7

[Steve Fink [:sfink] [:s:]]

Attachment: Fix faulty assertion involving user-defined structured clone tags

This previously asserted that the entry after the transfer map, if nonempty, contained a tag less than SCTAG_TRANSFER_MAP_HEADER, as that is where all of the standard tags live. However, user-defined tags start *above* the transfer map entries, so if the first object serialized was a user-defined object (eg a Blob), the assertion would fail.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3ed34ab50aca
Fix faulty assertion involving user-defined structured clone tags, r=terrence

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/3ed34ab50aca