Closed Bug 1654807 Opened 7 months ago Closed 6 months ago

[big endian] initializing nsTArray's header in thin_vec sets mIsAutoArray instead of mCapacity


(Core :: XPCOM, defect)

78 Branch



82 Branch
Tracking Status
firefox82 --- fixed


(Reporter: jhorak, Assigned: Gankra)


(Blocks 1 open bug)



(1 file)

The LocaleService class member variables gets corrupted when the fluent_langneg_negotiate_languages returns nsAutoTArray instead of nsTArray. This leads to later crash because mRequestedLocales array header is overwritten because mAppLocales is considered as nsAutoTArray (for example during SetLength(0) call).

This happens only on s390x. I really don't know to what is this related to.

Surprisingly the mCapacity and mIsAutoArray seems to be swapped:
S390X: (both there [1] )

(gdb) p *aRetVal.mHdr
$95 = {mLength = 1, mCapacity = 0, mIsAutoArray = 1}


(gdb) p *aRetVal.mHdr
$8 = {mLength = 1, mCapacity = 1, mIsAutoArray = 0}


Guys, did you noticed that in 78 ESR?

With some help I've been able to track this down, looks like bug in thin_vec:

type = struct nsTArrayHeader {
uint32_t mLength;
uint32_t mCapacity : 31;
uint32_t mIsAutoArray : 1;


struct Header {
    _len: SizeType,
    _cap: SizeType,

(no sign of mIsAutoArray)

x/8x aRetVal->mHdr
before fluent_langneg_negotiate_languages call:
0x3fff9d6b310 <sEmptyTArrayHeader>:     0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
after fluent_langneg_negotiate_languages call:
0x2aa00319dc0:                          0x00    0x00    0x00    0x01    0x00    0x00    0x00    0x01
(when manually setting mCapacity to 1 and resetting mIsAutoArray to 0 by using gdb)
0x2aa00319dc0:                          0x00    0x00    0x00    0x01    0x00    0x00    0x00    0x02
Component: Internationalization → XPCOM
Summary: [s390x] fluent_langneg_negotiate_languages returns nsAutoTArray while mAppLocales is nsTArray → [big endian] initializing nsTArray's header in thin_vec sets mIsAutoArray instead of mCapacity

thin-vec does handle the mIsAutoArray bit, but evidently we need to properly redefine AUTO_MASK/CAP_MASK on big endian platforms:

Assignee: nobody → a.beingessner

thin-vec 0.2.0 has been published with a tentative fix, but I'm not sure how to test a big endian configuration

I finally had a chance to test the fix on s390x and it seems to be working fine. I'm not sure I'm the right person to do the review but I can definitely give a positive feedback. If that's enough for you I'll give you the review.

Flags: needinfo?(a.beingessner)

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:Gankra, could you have a look please?
For more information, please visit auto_nag documentation.

Flags: needinfo?(a.beingessner)
Pushed by
update thin-vec to 0.2.1 for potential endianess fix. r=froydnj
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → 82 Branch
Flags: needinfo?(a.beingessner)
You need to log in before you can comment on or make changes to this bug.