1164244 - crash in std::deque<mozilla::gmp::GMPStorageChild::RecordIteratorContext, std::allocator<mozilla::gmp::GMPStorageChild::RecordIteratorContext> >::push_back(mozilla::gmp::GMPStorageChild::RecordIteratorContext&&)

Status: RESOLVED WONTFIX

(Core :: Audio/Video, defect, P1)

Description

[Chris Pearce [:cpearce (Not reading bugmail)]]

This bug was filed from the Socorro interface and is 
report bp-dae14c76-c077-4df5-8a8e-227a42150511.
=============================================================

See also:
https://crash-stats.mozilla.com/signature/?signature=std%3A%3Adeque%3Cmozilla%3A%3Agmp%3A%3AGMPStorageChild%3A%3ARecordIteratorContext%2C+std%3A%3Aallocator%3Cmozilla%3A%3Agmp%3A%3AGMPStorageChild%3A%3ARecordIteratorContext%3E+%3E%3A%3Apush_back%28mozilla%3A%3Agmp%3A%3AGMPStorageChild%3A%3ARecordIteratorContext%26%26%29&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&page=1

Crashing plugin-container GMP child process.

Comment 1

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Discussion with cpearce:
The stack doesn't really make much sense... Seems that the compositor is setting the exit handler or somesuch, which runs this code (GMPStorageChild::EnumerateRecords) which should only be in the child process.
This can't be us; this must be some other code that happens to compile to the same ABI as our code, and ends up being assigned our symbol name, so we're seeing the crash as in our code when it's not.
Looking at frame 1 of the crashing thread: it's also calling std::deque::push!

David, does this explanation seem likely to you?

Comment 2

[(Away)]

Yep, happens all the time.

Taking it one step further: whatever function that actually is, is still not at fault. The code has been corrupted:

63a765ac a984ef34e5      test    eax,0E534EF84h
63a765b1 85b5ada49a8c    test    dword ptr [ebp-73655B53h],esi
63a765b7 84ef            test    bh,ch
63a765b9 85b5adadad3d    test    dword ptr [ebp+3DADADADh],esi
63a765bf a4              movs    byte ptr es:[edi],byte ptr [esi]
63a765c0 ef              out     dx,eax

That doesn't look like typical disassembly, and it doesn't match what we shipped in that build.

Comment 3

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

- Code from the wrong process (child code, parent crash)
- Probably corrupted code
-> Won't fix this particular signature.