1338973 - Crash in nsCOMArray_base::InsertObjectsAt

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect, P3)

Description

[Nicholas Nethercote [inactive]]

This bug was filed from the Socorro interface and is 
report bp-dc02da85-ab54-456b-82ee-bf21c2170212.
=============================================================

We've had crashes with this signature in the past, but this feels like a new(ish) one. It's showing up on Nightly, Aurora, and Beta.

It's a shutdown crash, and the crash address is always 0x0, which suggests that aObjects is null.

Michal, any ideas?

Comment 1

[Michal Novotny [:michal]]

AFAICS, we always pass a pointer to a valid nsCOMArray<nsIFile> to the timer. Also the access to nsDeleteDir::mTimers is protected by a lock, so it cannot happen that nsDeleteDir::Shutdown uses a pointer to an array freed by nsDeleteDir::TimerCallback. So I have no theory :-/

Comment 2

[Chris Peterson [:cpeterson]]

Curiously, 100% of these (55) InsertObjectsAt crashes are on Win64 Firefox.

Comment 3

[Julien Cristau [:jcristau] (back April 22)]

Too late for firefox 52, mass-wontfix.

Comment 4

[Patrick McManus [:mcmanus]]

can getclosure() ever return null if it races against wanting to run the timer perhaps? This might be the only use of getclosure) in gecko :)

maybe just "if (finishDeleting && *arg)" to protect against the timer class doing something unanticipated?

might not be worth overthinking.

Comment 5

[Firefox Bug Husbandry Bot]

Bulk priority update: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 24 weeks.

Comment 7

[Michal Novotny [:michal]]

None of the reports this year has cache on the stack. Most of them are coming from nsThreadPool::Shutdown().

Comment 8

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

Closing because no crashes reported for 12 weeks.