[wayland] leakcheck: default leaked 1 nsWaylandDisplay
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
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
Comment 1•2 years ago
|
||
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?
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 2•2 years ago
|
||
(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 justdisplay = 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.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 3•2 years ago
|
||
Should be fixed now by Bug 1829303. Can you check with latest nightly please?
Thanks.
Reporter | ||
Comment 4•2 years ago
|
||
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
Assignee | ||
Comment 5•2 years ago
|
||
(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.
Assignee | ||
Comment 6•2 years ago
|
||
Is there any way how to find which string leaks?
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 7•2 years ago
|
||
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.
Reporter | ||
Comment 8•2 years ago
|
||
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).
Updated•1 years ago
|
Description
•