1828618 - [wayland] leakcheck: default leaked 1 nsWaylandDisplay

Status: RESOLVED DUPLICATE of bug 1829303

(Core :: Widget: Gtk, defect, P3)

Description

[Manuel Bucher [:manuel]]

I have a relative new leak occuring (maybe introduced <=2 weeks ago?) on gnome wayland

I'm on GNOME Shell 43.4.

Running tests (observed with ./mach test netwerk/test/browser/browser_103_cleanup.js). This leak only occures when running without --headless.

My buildconfig is buildwith debug noopt

 0:56.27 INFO leakcheck | Processing leak log file /tmp/tmpmt3dsz0o.mozrunner/runtests_leaks.log
 0:56.27 INFO 
 0:56.27 INFO == BloatView: ALL (cumulative) LEAK AND BLOAT STATISTICS, default process 169497
 0:56.27 INFO 
 0:56.27 INFO      |<----------------Class--------------->|<-----Bytes------>|<----Objects---->|
 0:56.27 INFO      |                                      | Per-Inst   Leaked|   Total      Rem|
 0:56.27 INFO    0 |TOTAL                                 |       51      120| 1112976        1|
 0:56.27 INFO 2070 |nsWaylandDisplay                      |      120      120|       1        1|
 0:56.27 INFO 
 0:56.27 INFO nsTraceRefcnt::DumpStatistics: 2138 entries
 0:56.27 INFO leakcheck: default leaked 1 nsWaylandDisplay
 0:56.27 UNEXPECTED-FAIL leakcheck: default 120 bytes leaked

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Yeah, fairly sure this is a regression from bug 1825170.

Martin, you've been looking at improving nsWaylandDisplay access. I suspect we can just display = nullptr there as other threads shouldn't try to access a shot down display, but maybe your refactorings help here or you have other ideas?

Comment 3

[Martin Stránský [:stransky] (ni? me)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

Yeah, fairly sure this is a regression from bug 1825170.

Martin, you've been looking at improving nsWaylandDisplay access. I suspect we can just display = nullptr there as other threads shouldn't try to access a shot down display, but maybe your refactorings help here or you have other ideas?

I have WIP patches so I'll handle it.

Comment 5

[Martin Stránský [:stransky] (ni? me)]

Should be fixed now by Bug 1829303. Can you check with latest nightly please?
Thanks.

Comment 6

[Manuel Bucher [:manuel]]

I do get a new leak now. I get when running with and without --background. But the other leak is fixed. I can't find a bug for the new leak. Do we want to open a new bug?

 0:58.03 INFO leakcheck | Processing leak log file /tmp/tmpvl6bsefs.mozrunner/runtests_leaks.log
 0:58.03 INFO 
 0:58.03 INFO == BloatView: ALL (cumulative) LEAK AND BLOAT STATISTICS, default process 200320
 0:58.03 INFO 
 0:58.03 INFO      |<----------------Class--------------->|<-----Bytes------>|<----Objects---->|
 0:58.03 INFO      |                                      | Per-Inst   Leaked|   Total      Rem|
 0:58.03 INFO    0 |TOTAL                                 |       51        8| 1164595        1|
 0:58.04 INFO 1990 |nsStringBuffer                        |        8        8|  164138        1|
 0:58.04 INFO 
 0:58.04 INFO nsTraceRefcnt::DumpStatistics: 2142 entries
 0:58.04 INFO leakcheck: default leaked 1 nsStringBuffer
 0:58.04 UNEXPECTED-FAIL leakcheck: default 8 bytes leaked

Comment 7

[Martin Stránský [:stransky] (ni? me)]

(In reply to Manuel Bucher [:manuel] from comment #6)

I do get a new leak now. I get when running with and without --background. But the other leak is fixed. I can't find a bug for the new leak. Do we want to open a new bug?

Let's use this one.

Comment 8

[Martin Stránský [:stransky] (ni? me)]

Is there any way how to find which string leaks?

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Manuel, I tested latest build with ASAN and I can't reproduce the nsStringBuffer leak (but I see other gfx leaks).
Can you point me to a test which fails here? (I used ./mach test netwerk/test/browser/browser_103_cleanup.js and also different ones).
Thanks.

Comment 10

[Manuel Bucher [:manuel]]

It's on any test, but also with --headless. For example with ./mach test netwerk/test/browser/browser_103_cleanup.js --headless. It's probably unrelated to wayland now and I don't think there is an easy way to see which string caused the build failure. Let's track this in a different bug. (I don't see other gfx leaks).