1410768 - TEST-UNEXPECTED-FAIL | leakcheck | default process: 2216 bytes leaked (BackstagePass, PrefCallback, XPCNativeInterface, XPCNativeMember, XPCNativeSet, ...)

Status: RESOLVED WORKSFORME

(Core :: XPConnect, enhancement, P3)

Description

[Dorel Luca [:dluca]]

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

https://tools.taskcluster.net/groups/LCEhLIUITxCMazTlhF4F-w/tasks/EeqAr8r4SumsLxGTeAPoJw/runs/0/logs/public%2Flogs%2Flive_backing.log

Comment 1

[Ryan VanderMeulen [:RyanVM]]

I assume "ASSERTION: 1 dynamic atom(s) with non-zero refcount: [System Principal]: 'nonZeroRefcountAtomsCount == 0', file /builds/worker/workspace/build/src/xpcom/ds/nsAtomTable.cpp, line 350" prior to that is related.

Comment 2

[Nathan Froyd [:froydnj]]

It's sort of related, but what that says is somebody is holding onto the atom, rather than that the atom itself is the cause of the leak.  There's a lot of XPConnect stuff in that leak, so I'm going to tentatively go with that.

Comment 3

[Andrew McCreight [:mccr8]]

We really need something that will print out info about a BackstagePass when it leaks. Maybe for atoms, too, though I don't know if they are still often leaking by themselves.

Comment 4

[Nathan Froyd [:froydnj]]

(In reply to Andrew McCreight [:mccr8] from comment #3)
> We really need something that will print out info about a BackstagePass when
> it leaks. Maybe for atoms, too, though I don't know if they are still often
> leaking by themselves.

Bug 1410209 wants to add names for leaking runnables in the leak logs; I suggested nsGlobalWindow as another class, and I could see describing Mutexes, nsThreads, etc. as also being useful.  Perhaps we should have something like:

NS_IMPL_ADDREF_WITH_DESCRIPTION(klassname, lambda)

where `lambda` will receive (void*, nsACString&), and can then stuff whatever it likes in the string outparam?  And then we can call the lambda where things leak?  We can store a std::function<(void*, nsACString&)> somewhere in nsTraceRefcnt, and that function can be null for the vast majority of things.  We'd have to be careful to not construct the function everytime we addref'd, of course.