1203273 - Crash in js::TraceManuallyBarrieredGenericPointerEdge after corruption (Mac OS X)

Status: RESOLVED INCOMPLETE

(Core :: JavaScript: GC, defect, P3)

Description

[alex_mayorga]

This bug was filed from the Socorro interface and is 
report bp-b3441f0b-8fcf-45f1-b024-e08f22150907.
=============================================================

Top crashed #5 for OS X in release.

Seems related to scrolling on Facebook from comments.

Crashing Thread
Frame 	Module 	Signature 	Source
0 	XUL 	js::TraceManuallyBarrieredGenericPointerEdge(JSTracer*, js::gc::Cell**, char const*) 	js/src/gc/Heap.h
1 	XUL 	js::gc::GCRuntime::markBufferedGrayRoots(JS::Zone*) 	js/src/gc/RootMarking.cpp
2 	XUL 	void js::gc::GCRuntime::markGrayReferences<js::gc::GCZoneGroupIter, js::CompartmentsIterT<js::gc::GCZoneGroupIter> >(js::gcstats::Phase) 	js/src/jsgc.cpp
3 	XUL 	js::gc::GCRuntime::endMarkingZoneGroup() 	js/src/jsgc.cpp
4 	XUL 	js::gc::GCRuntime::sweepPhase(js::SliceBudget&) 	js/src/jsgc.cpp
5 	XUL 	js::gc::GCRuntime::incrementalCollectSlice(js::SliceBudget&, JS::gcreason::Reason) 	js/src/jsgc.cpp
6 	XUL 	js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, JS::gcreason::Reason) 	js/src/jsgc.cpp
7 	XUL 	js::gc::GCRuntime::collect(bool, js::SliceBudget, JS::gcreason::Reason) 	js/src/jsgc.cpp
8 	XUL 	JS::IncrementalGCSlice(JSRuntime*, JS::gcreason::Reason, long long) 	js/src/jsgc.cpp
9 	XUL 	nsJSContext::GarbageCollectNow(JS::gcreason::Reason, nsJSContext::IsIncremental, nsJSContext::IsShrinking, long long) 	dom/base/nsJSEnvironment.cpp
10 	XUL 	nsTimerImpl::Fire() 	xpcom/threads/nsTimerImpl.cpp
11 	XUL 	nsTimerEvent::Run() 	xpcom/threads/nsTimerImpl.cpp
12 	XUL 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp
13 	XUL 	NS_ProcessPendingEvents(nsIThread*, unsigned int) 	xpcom/glue/nsThreadUtils.cpp
14 	XUL 	nsBaseAppShell::NativeEventCallback() 	widget/nsBaseAppShell.cpp
15 	XUL 	nsAppShell::ProcessGeckoEvents(void*) 	widget/cocoa/nsAppShell.mm
Ø 16 	CoreFoundation 	CoreFoundation@0x80a00 	
Ø 17 	CoreFoundation 	CoreFoundation@0x72b8c 	
Ø 18 	CoreFoundation 	CoreFoundation@0x721be 	
Ø 19 	CoreFoundation 	CoreFoundation@0x71bd7 	
Ø 20 	HIToolbox 	HIToolbox@0x3256e 	
Ø 21 	HIToolbox 	HIToolbox@0x322e9 	
Ø 22 	HIToolbox 	HIToolbox@0x3212a 	
Ø 23 	AppKit 	AppKit@0x918aa 	
Ø 24 	AppKit 	AppKit@0x90e57 	
Ø 25 	AppKit 	AppKit@0x15eddd 	
Ø 26 	AppKit 	AppKit@0x15d230

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I just crashed on Fx42 beta (which might be the one going out to release in the next day or two) via:

bp-91472f8f-71b5-4e78-8213-2f6f72151102

Setting needinfo? from GC folks on this. I might just have been scrolling a page too, not sure.

Comment 2

[Terrence Cole [:terrence]]

Out of markBufferedGrayRoots. This is heap corruption somewhere in the browser: totally unactionable without STR.

Comment 3

[Jesper Hansen]

This bug just hit the release of 42

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to Jesper Hansen from comment #3)
> This bug just hit the release of 42

It hit you?

https://crash-stats.mozilla.com/search/?product=Firefox&signature=~js%3A%3ATraceManuallyBarrieredGenericPointerEdge&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#crash-reports seems to indicate it's pretty much gone after 42

https://crash-stats.mozilla.com/search/?product=Firefox&signature=~js%3A%3ATraceManuallyBarrieredGenericPointerEdge&version=44.0&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#crash-reports  WFM?

Comment 5

[Wayne Mery (:wsmwk)]

only 4 version 44 crashes https://crash-stats.mozilla.com/search/?product=Firefox&signature=~js%3A%3ATraceManuallyBarrieredGenericPointerEdge&version=44.0&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#crash-reports 

 WFM?

Comment 6

[Jesper Hansen]

I had bp-446cc5f7-8807-42d1-814d-fa1ad2151201

But it seems this was fixed somewhere between 44.0b9 and 44.0 (release). Or we just haven't had a single crash past that point.

Reopen if a crash is met

Comment 7

[alex_mayorga]

¡Hola Jesper, Wayne!

I see 5 crashes on 47.0a1, 4 in 45.0b3 and a total of 225 crashes in the past week at https://crash-stats.mozilla.com/report/list?product=Firefox&signature=js%3A%3ATraceManuallyBarrieredGenericPointerEdge

Shall this be reopened?

¡Gracias!

Comment 8

[Jesper Hansen]

I don't see a common denominator between these reports myself

Comment 9

[Wayne Mery (:wsmwk)]

Alex has a ton of crashes. So without clear STR it's awfully hard to say if a crash with signature A on day B is the same as a crash with signature A on day C.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature 'js::TraceManuallyBarrieredGenericPointerEdge':
 - nightly (version 50): 0 crash from 2016-06-06.
 - aurora  (version 49): 224 crashes from 2016-06-07.
 - beta    (version 48): 68 crashes from 2016-06-06.
 - release (version 47): 225 crashes from 2016-05-31.
 - esr     (version 45): 5 crashes from 2016-04-07.

Crash volume on the last weeks:
             Week N-1   Week N-2   Week N-3   Week N-4   Week N-5   Week N-6   Week N-7
 - nightly          0          0          0          0          0          0          0
 - aurora          42         25         38         40         36         29          4
 - beta             2         16         10          6         12         12          7
 - release         31         27         35         45         29         35         12
 - esr              0          1          0          1          1          2          0

Affected platforms: Windows, Mac OS X, Linux

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature 'js::TraceManuallyBarrieredGenericPointerEdge':
 - nightly (version 51): 16 crashes from 2016-08-01.
 - aurora  (version 50): 0 crashes from 2016-08-01.
 - beta    (version 49): 202 crashes from 2016-08-02.
 - release (version 48): 35 crashes from 2016-07-25.
 - esr     (version 45): 13 crashes from 2016-05-02.

Crash volume on the last weeks (Week N is from 08-22 to 08-28):
            W. N-1  W. N-2  W. N-3
 - nightly       7       6       1
 - aurora        0       0       0
 - beta         72      67      22
 - release      13       9       4
 - esr           2       3       1

Affected platforms: Windows, Mac OS X, Linux

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly #226      #266
 - aurora
 - beta    #220      #283
 - release #1312
 - esr     #4673

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature 'js::TraceManuallyBarrieredGenericPointerEdge':
 - nightly (version 52): 1 crash from 2016-09-19.
 - aurora  (version 51): 0 crashes from 2016-09-19.
 - beta    (version 50): 19 crashes from 2016-09-20.
 - release (version 49): 867 crashes from 2016-09-05.
 - esr     (version 45): 19 crashes from 2016-06-01.

Crash volume on the last weeks (Week N is from 10-03 to 10-09):
            W. N-1  W. N-2
 - nightly       1       0
 - aurora        0       0
 - beta         12       7
 - release     738     129
 - esr           0       3

Affected platforms: Windows, Mac OS X, Linux

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly #985
 - aurora
 - beta    #1705     #513
 - release #98       #37
 - esr

Comment 13

[Adam Roach [:abr]]

Socorro shows that this crash signature has been increasing at a nearly linear (and quite alarming) rate since the beginning of March, after being stable and low for several months. We probably want to re-prioritize this during our next regression triage; tagging accordingly.

Comment 14

[Adam Roach [:abr]]

Tagging Randall as the 53 release boss (redirect as appropriate -- sorry if this isn't the right course of action!) See bp-c16cba4c-372b-445d-9ef1-c552d2170323 for a representative FFx53 crash.

Comment 15

[Andrew McCreight [:mccr8]]

This could just be a signature change due to different inlining. There are a ton of these crashes on 52, but barely any on other branches. If you look at bug 1280591, there are a lot of crashes on 51, but not many on newer versions. We're supposed to tag crashes that happen during GC, but maybe it isn't stored properly for content process crashes.

These crashes are supposedly null, which suggests we could do something, but IIRC poison values show up as null on OSX, so who knows.

Comment 16

[Intermittent Failures Robot]

1 failures in 824 pushes (0.001 failures/push) were associated with this bug in the last 7 days.    

Repository breakdown:
* autoland: 1

Platform breakdown:
* macosx64-stylo-disabled: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1203273&startday=2017-10-02&endday=2017-10-08&tree=all

Comment 17

[David Bolter [:davidb] (NeedInfo me for attention)]

The vast majority of these are still OSX... A couple of linux stacks for a few days ago:
bp-255693a7-0c21-4111-8def-0e7600171106
bp-4ed11b7a-0b88-4947-ae33-6ffe00171105

Drive by naive question: could we bail on the null cases on release channel?

Comment 18

[Jon Coppeard (:jonco)]

(In reply to David Bolter [:davidb] (NeedInfo me for attention) from comment #17)
Most of the stacks show us crashing under js::TraceManuallyBarrieredGenericPointerEdge, in a call to Cell::isTenured().  But TraceManuallyBarrieredGenericPointerEdge already checks the cell pointer is not null so it's hard to see how this can happen, or how we could add an extra check.

Comment 19

[Randell Jesup [:jesup] (needinfo me)]

A moderate number of these crashes are non-nullptrs (real ptrs or trashed ptrs), with at least 1 EXEC wildptr crash (https://crash-stats.mozilla.com/report/index/a13442bb-36b3-4029-bd2c-7c0db0171108).
Likely a form of UAF.

This is a really odd set of addresses to crash on... (I sorted by address, 6 months, and like 3,4,5 pages in look at the sequence of addresses).  Likely just indication that the memory is freed and being trashed.

https://crash-stats.mozilla.com/signature/?signature=js%3A%3ATraceManuallyBarrieredGenericPointerEdge&date=%3E%3D2017-05-08T17%3A23%3A08.000Z&date=%3C2017-11-08T15%3A23%3A08.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-address&_sort=-date&page=5

A single crash is for e5e5, and this may be something else entirely:
https://crash-stats.mozilla.com/report/index/c82a257a-79c9-4ce2-a5ca-a96900170906

Comment 20

[Daniel Veditz [:dveditz]]

The mac "null" crashes I looked at had registers
  "rax": "0xe5e5e5e5e5e5e5e5"
  "rcx": "0xe5e5e5e5e5e00000"

Comment 21

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Daniel Veditz [:dveditz] from comment #20)
> The mac "null" crashes I looked at had registers
>   "rax": "0xe5e5e5e5e5e5e5e5"
>   "rcx": "0xe5e5e5e5e5e00000"

Yeah, that's not encouraging and would tend to point to UAF - which isn't surprising given the previous analysis

Comment 22

[Frederik Braun [:freddy]]

(In reply to Jon Coppeard (:jonco) from comment #18)
> (In reply to David Bolter [:davidb] (NeedInfo me for attention) from comment
> #17)
> Most of the stacks show us crashing under
> js::TraceManuallyBarrieredGenericPointerEdge, in a call to
> Cell::isTenured().  But TraceManuallyBarrieredGenericPointerEdge already
> checks the cell pointer is not null so it's hard to see how this can happen,
> or how we could add an extra check.

Do you think an extra check is worth the effort?

Comment 23

[Jon Coppeard (:jonco)]

(In reply to Daniel Veditz [:dveditz] from comment #20)
> The mac "null" crashes I looked at had registers
>   "rax": "0xe5e5e5e5e5e5e5e5"
>   "rcx": "0xe5e5e5e5e5e00000"

This lead me to believe that the crash address is not always accurate.  With these register values I would expect a crash at an address starting with 0xe5e5e.... in IsInsideNursery().  But other crash addresses are consistent with the stack shown.

Comment 24

[Jon Coppeard (:jonco)]

(In reply to Jon Coppeard (:jonco) from comment #23)
Oh right, that's bug 974420.

So many of these crashes are probably at 0xe5e5e5e5e5efffe8.

The pointers in question are accessed when they are passed in by the cycle collector, so they can't be bad at that point.  They're placed in a vector on the zone.  The zone memory is allocated by jemalloc; if the zone had been freed we would get a UAF crash at an earlier point.  So that indicates that the vector's storage has been independently freed somehow.  That doesn't make a lot of sense though.

Comment 25

[Jon Coppeard (:jonco)]

Attachment: bug1203273-gray-buffer-check

I don't see how this can possibly happen, but what do you think of adding a canary value to the end of the gray buffer vectors to check if the storage has disappeared from underneath us?

Comment 26

[Randell Jesup [:jesup] (needinfo me)]

r? to you....

Comment 27

[Jon Coppeard (:jonco)]

Comment on attachment 8941917 [details] [diff] [review]
bug1203273-gray-buffer-check

[Security approval request comment]

This is not a fix, but asking for sec-approval anyway just in case.

How easily could an exploit be constructed based on the patch?  Very hard.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?  They indicate a possible problem, but not how to trigger it.

Which older supported branches are affected by this flaw?  Unknown but crash rate increased in March 2017.

If not all supported branches, which bug introduced the flaw?  Unknown.

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?  N/A.

How likely is this patch to cause regressions; how much testing does it need?  Unlikely.

Comment 28

[Al Billings [:abillings - ex-MoCo]]

(In reply to Jon Coppeard (:jonco) from comment #27)
> Comment on attachment 8941917 [details] [diff] [review]
> bug1203273-gray-buffer-check
> 
> [Security approval request comment]
> 
> This is not a fix, but asking for sec-approval anyway just in case.

Is this a diagnostic patch?

Comment 29

[Jon Coppeard (:jonco)]

(In reply to Al Billings [:abillings] from comment #28)
> Is this a diagnostic patch?

Yes.

Comment 30

[Al Billings [:abillings - ex-MoCo]]

Comment on attachment 8941917 [details] [diff] [review]
bug1203273-gray-buffer-check

sec-approval+

Comment 31

[Jon Coppeard (:jonco)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b1dacff4b3744f303f04ad9f53c670608af8b17a

Comment 32

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/b1dacff4b374

Comment 33

[Ryan VanderMeulen [:RyanVM]]

Anything interesting in the recent trunk crashes? Should we consider uplifting the diagnostic patch to Beta as well where we seem to be getting a few more reports?

Comment 34

[Jon Coppeard (:jonco)]

Comment on attachment 8941917 [details] [diff] [review]
bug1203273-gray-buffer-check

Approval Request Comment
[Feature/Bug causing the regression]: Unknown, this is a diagnostic patch.
[User impact if declined]: None.
[Is this code covered by automated tests?]: Yes.
[Has the fix been verified in Nightly?]: Yes.
[Needs manual test from QE? If yes, steps to reproduce]:  No.
[List of other uplifts needed for the feature/fix]: None.
[Is the change risky?]: No.
[Why is the change risky/not risky?]: This just adds a release-mode assertion that the end of the gray roots buffer has not been corrupted.
[String changes made/needed]: None.

Comment 35

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8941917 [details] [diff] [review]
bug1203273-gray-buffer-check

Diagnostic patch to hopefully help track down some tricky crashes. Approved for 60.0b11.

Comment 36

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/eafdd39a64d3

Comment 37

[Jon Coppeard (:jonco)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #33)
There are three crashes on beta since we uploaded this patch, one hitting the assert (so the contents of our vector have been corrupted), and two crashing despite passing the (admittedly imperfect) check.

Comment 38

[Randell Jesup [:jesup] (needinfo me)]

Jonco - there are now quite a few crashes on beta with your diagnostic.  Any updates?

Comment 39

[Jon Coppeard (:jonco)]

(In reply to Randell Jesup [:jesup] from comment #38)
I can only find one crash where it actually hits the assert I added (out of ~50 for the beta channel).

It's interesting that most of these crashes are on OSX, but I don't know whether the same problem shows up under a different signature elsewhere (if the new assertion fails that would show up under this signature for sure though).

I had another look at the code today but didn't come up with anything.  It still seems like somehow the vector's buffer is being freed from under us, which obviously should not be possible.

Comment 40

[Ryan VanderMeulen [:RyanVM]]

I don't see much point in tracking this bug across every release. Obviously we'll strongly consider taking a fix if/when we make progress on finding the root cause.

Comment 42

[Ted Campbell [:tcampbell]]

Folding Bug 1280591 into this one for easier signature tracking. 95% of these barrier crashes are within markBufferedGrayRoots.

Comment 43

[Ted Campbell [:tcampbell]]

(When looking at the graph, make sure to use Exact match or the js:: will show every JS crash)

Comment 44

[Ted Campbell [:tcampbell]]

Sorry for the churn...

Removing those signatures because they only occur in FF48 ESR45 (which still live because of OSX users on ancient OS versions). The spike in crashes on FF48 at the beginning of February is a little unsettling, but I'm not sure there is much do to for those versions.

Comment 45

[Ted Campbell [:tcampbell]]

Jan, while I have you peeking at OSX dumps.. do you mind taking a look at this for any indication about what object we are hitting here?

Presumably this is a OSX-specific element missing it's ExposeToActiveJS call.

Comment 46

[Jon Coppeard (:jonco)]

(In reply to Ted Campbell [:tcampbell] from comment #45)
> Presumably this is a OSX-specific element missing it's ExposeToActiveJS call.

It looks like a Vector's heap buffer is being freed somehow.  The pointers are valid when they're put into the buffer because we call zoneFromAnyThread() on them.

Looking at the stats again I don't see any crashes on 60 yet though which I would have expected.  If this does start to show up in 60 I'll make a more comprehensive diagnostic patch that dumps memory addresses, buffer contents etc.

Comment 47

[Ted Campbell [:tcampbell]]

My bad. The name went back to markBufferedGrayRoots again in FF60.

Comment 48

[Jon Coppeard (:jonco)]

Attachment: bug1203273-gray-buffer-diagnostics

The canary check didn't catch anything so remove it and sanity check each pointer in the buffer as we go, on OSX only and not in release.

Comment 49

[Jon Coppeard (:jonco)]

Comment on attachment 8980599 [details] [diff] [review]
bug1203273-gray-buffer-diagnostics

Requesting approval for diagnostic patch.

[Security approval request comment]
How easily could an exploit be constructed based on the patch? Impossible.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? No.

Which older supported branches are affected by this flaw? Unknown, probably all.

If not all supported branches, which bug introduced the flaw? Unknown.

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be? This patch should apply.

How likely is this patch to cause regressions; how much testing does it need? Very unlikely.

Comment 50

[Al Billings [:abillings - ex-MoCo]]

sec-approval+ for new diagnostic patch.

Comment 51

[Jon Coppeard (:jonco)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a7826942ef6bf60ff67d7ad075d17285725d0211

Comment 52

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/a7826942ef6b

Comment 53

[Jon Coppeard (:jonco)]

Comment on attachment 8980599 [details] [diff] [review]
bug1203273-gray-buffer-diagnostics

It would be great to get this diagnostic patch onto beta.

Approval Request Comment
[Feature/Bug causing the regression]: Unknown, diagnostic patch.
[User impact if declined]: None.
[Is this code covered by automated tests?]: Yes.
[Has the fix been verified in Nightly?]: Yes.
[Needs manual test from QE? If yes, steps to reproduce]: No.
[List of other uplifts needed for the feature/fix]: None.
[Is the change risky?]: No.
[Why is the change risky/not risky?]: This adds an assertion that is only checked on beta/nightly on OSX.
[String changes made/needed]: None.

Comment 54

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8980599 [details] [diff] [review]
bug1203273-gray-buffer-diagnostics

Adds diagnostics to try to get to the root cause of this crash. Approved for 61.0b10.

Comment 55

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8980599 [details] [diff] [review]
bug1203273-gray-buffer-diagnostics

https://hg.mozilla.org/releases/mozilla-beta/rev/57f7d2058ce2

Clearing the beta approval to get this off the needs-uplift radar.

Comment 56

[Jon Coppeard (:jonco)]

Since the last diagnostic patch landed we've hit the MOZ_CRASH twice:

Bad GC thing pointer in gray root buffer: 0xe5e5e5e5e5e5e5e5 at index 0 of 18810, address 0x1f3059000
Bad GC thing pointer in gray root buffer: 0xe5e5e5e5e5e5e5e5 at index 0 of 25222, address 0x1b6a02000

Again this suggests the Vector's buffer has somehow been freed.

Comment 57

[Andrew Overholt [:overholt]]

(In reply to Jon Coppeard (:jonco) from comment #56)
> Again this suggests the Vector's buffer has somehow been freed.

Do we know how that could be happening? Should we ask if the pernosco people can try catching this in their tool?

Comment 58

[Jon Coppeard (:jonco)]

(In reply to Andrew Overholt [:overholt] from comment #57)
No, nothing should be able to free the Vector's buffer underneath it like this.  If we can somehow catch this happening that would be great...

Comment 59

[Randell Jesup [:jesup] (needinfo me)]

The problem is that we have no way to drive a crash for this; we're relying on reports (rare) from the field.  Without some hope of hitting it in automation, pernosco can't help us.

Comment 60

[Nicolas B. Pierron [:nbp | PTO until 11/11]]

(In reply to Jon Coppeard (:jonco) from comment #56)
> Bad GC thing pointer in gray root buffer: 0xe5e5e5e5e5e5e5e5 at index 0 of
> 18810, address 0x1f3059000
> Bad GC thing pointer in gray root buffer: 0xe5e5e5e5e5e5e5e5 at index 0 of
> 25222, address 0x1b6a02000
> 
> Again this suggests the Vector's buffer has somehow been freed.

We see the similar things with the LifoAlloc buffers (Bug 1263794 & Bug 1112741) and the Assembly buffers (Bug 1124397).

Comment 61

[Andrew Overholt [:overholt]]

Randell, did we ever decide on a sec-stalled keyword?

Jon and I have discussed this a bunch and there's no way forward we can see here.

One last attempt is seeing if glandium has thoughts about how this memory could be getting freed?

Comment 62

[Mike Hommey [:glandium]]

That's typically the kind of things we'd catch with asan. A good way forward on these kinds of bugs would be to ship the asan nightlies on more platforms (I think that's in the pipe?) and possibly contacting the people who got such crashes and invite them to try asan nightlies for a while. BTW, do we have any idea if the people who get those crashes get more than one?

Comment 63

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Andrew Overholt [:overholt] from comment #61)
> Randell, did we ever decide on a sec-stalled keyword?

No - we need to.   Filed bug 1480097

Comment 64

[Adam Roach [:abr]]

(In reply to Mike Hommey [:glandium] from comment #62)
> BTW, do we
> have any idea if the people who get those crashes get more than one?

I'm only one data point, but I suppose that's better than none...

I've never had this particular crash occur on Firefox. I'll go through long periods of time where Thunderbird encounters this crash approximately two to three times a month, and then it goes quiescent. I haven't seen it for many months now.

Comment 65

[Liz Henry (:lizzard) (relman/hg->git project)]

Untracking for 62 since this isn't currently actionable.

Comment 66

[Ted Campbell [:tcampbell]]

Stalled. We haven't been able to identify anything more specific here than general corruption or UAF similar to what we see in other places.

Comment 67

[BugBot [:suhaib / :marco/ :calixte]]

The leave-open keyword is there and there is no activity for 6 months.
:jonco, maybe it's time to close this bug?

Comment 68

[Jon Coppeard (:jonco)]

This is an ongoing crash. I think it's helpful to keep the bug open.

Comment 69

[Wayne Mery (:wsmwk)]

For Thunderbird, the majority of crashes are no longer Mac, for example js::TraceManuallyBarrieredGenericPointerEdge bp-fadb1e6e-1aff-4dc8-a4af-742720200403

Comment 70

[alex_mayorga]

Updated flags per https://crash-stats.mozilla.org/signature/?signature=js%3A%3ATraceManuallyBarrieredGenericPointerEdge&date=%3E%3D2021-02-01T22%3A01%3A00.000Z&date=%3C2021-08-01T22%3A01%3A00.000Z

Comment 71

[Jon Coppeard (:jonco)]

The gray root buffer was removed in bug 1730140 which is what most of the crashes in this bug originally came from. TraceManuallyBarrieredGenericPointerEdge is a generic signature though and we will continue to see crashes here.

Comment 72

[Ted Campbell [:tcampbell]]

(In reply to Jon Coppeard (:jonco) from comment #71)

The gray root buffer was removed in bug 1730140 which is what most of the crashes in this bug originally came from. TraceManuallyBarrieredGenericPointerEdge is a generic signature though and we will continue to see crashes here.

Comment 73

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit auto_nag documentation.