Closed Bug 1828618 Opened 2 years ago Closed 2 years ago

[wayland] leakcheck: default leaked 1 nsWaylandDisplay

Categories

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

x86_64
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 1829303
Tracking Status
firefox-esr102 --- unaffected
firefox112 --- unaffected
firefox113 --- wontfix
firefox114 --- fixed
firefox115 --- fixed

People

(Reporter: manuel, Assigned: stransky)

References

(Blocks 2 open bugs)

Details

(Keywords: regression)

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

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?

Flags: needinfo?(stransky)
Keywords: regression
Flags: needinfo?(stransky)

(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.

Priority: -- → P3
Assignee: nobody → stransky
Flags: needinfo?(stransky)
Blocks: 1828255
Flags: needinfo?(stransky)

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

Flags: needinfo?(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
Flags: needinfo?(manuel)

(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.

Is there any way how to find which string leaks?

Flags: needinfo?(stransky)

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.

Flags: needinfo?(stransky) → needinfo?(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).

Status: NEW → RESOLVED
Closed: 2 years ago
Duplicate of bug: 1829303
Flags: needinfo?(manuel)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.