1303441 - Intermittent LeakSanitizer | leak at mozilla::storage::StorageBaseStatementInternal::destructorAsyncFinalize, mozilla::storage::AsyncStatement::~AsyncStatement, mozilla::storage::AsyncStatement::Release

Status: RESOLVED WORKSFORME

(Core :: SQLite and Embedded Database Bindings, defect, P3)

Description

[Treeherder Bug Filer]

Filed by: wkocher [at] mozilla.com

https://treeherder.mozilla.org/logviewer.html#?job_id=3625944&repo=autoland

https://queue.taskcluster.net/v1/task/Qho_kaVoQ5WjchAqjMutvA/runs/0/artifacts/public%2Flogs%2Flive_backing.log

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

This is fallout from https://groups.google.com/forum/#!topic/mozilla.dev.platform/xN-K5kEsq7A and bug 1155059.  Specifically, Connection::getAsyncExecutionTarget() hands us an nsIEventTarget (that is not our current thread) and we try to dispatch to it, but fail.  The failure causes a leak because it intentionally took ownership of our finalizer in order to avoid accidental releasing on the main thread.

The code expects getAsyncExecutionTarget() to prevent this type of thing from happening since it has a shutdown guard.  Presumably "xpcom-shutdown-threads" has happened and gXPCOMThreadsShutDown=true.  mozStorage's xpcom-shutdown-threads observer does not directly impact getAsyncExecutionTarget(), leading to this sequence of events.  I think we should ensure this gets fixed as part of bug 1186276.