Closed
Bug 1284603
Opened 8 years ago
Closed 8 years ago
leaks after clicking on an event in google calendar
Categories
(Core :: DOM: Core & HTML, defect, P2)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: dbaron, Unassigned)
Details
(Keywords: memory-leak, Whiteboard: [MemShrink:P2][platform-rel-Google][platform-rel-GoogleCalendar])
Attachments
(6 files, 1 obsolete file)
I regularly see the "Leaked URLs" printout at shutdown show google calendar URLs in it. I've found that I've been able to reproduce the leak with the following relatively simple steps: 1. set up a clean profile logged in to my google account, set to save tabs at shutdown, with google calendar in a pinned tab and the firefox start page in a non-pinned tab, with the pinned tab active 2. start up Firefox with this profile 3. click on an event so the "popup" pops open 4. click the [X] in the popup 5. quit Firefox (File -> Quit) This results in the following printed out at the end of shutdown: Leaked URLs: https://calendar.google.com/calendar/render#main_7 https://calendar.google.com/calendar/perf https://calendar.google.com/calendar/render nsStringStats => mAllocCount: 38390 => mReallocCount: 860 => mFreeCount: 38363 -- LEAKED 27 !!! => mShareCount: 37423 => mAdoptCount: 5291 => mAdoptFreeCount: 5291 => Process ID: 2269, Thread ID: 140285329734400 ... Leaked URLs: https://calendar.google.com/calendar/perf https://calendar.google.com/calendar/perf https://calendar.google.com/calendar/render https://calendar.google.com/calendar/render#main_7 https://calendar.google.com/calendar/render#main_7 https://calendar.google.com/calendar/render#main_7 nsStringStats => mAllocCount: 92042 => mReallocCount: 7046 => mFreeCount: 92002 -- LEAKED 40 !!! => mShareCount: 84116 => mAdoptCount: 5136 => mAdoptFreeCount: 5134 -- LEAKED 2 !!! => Process ID: 2225, Thread ID: 140071844366144
Reporter | ||
Comment 1•8 years ago
|
||
Reporter | ||
Comment 2•8 years ago
|
||
Reporter | ||
Updated•8 years ago
|
Attachment #8768133 -
Attachment mime type: text/x-log → text/plain
Reporter | ||
Comment 3•8 years ago
|
||
(but sometimes the child process doesn't leak and only the parent process does)
Reporter | ||
Comment 4•8 years ago
|
||
When I *don't* see the leaks in the child, I see this stack of rather late destruction of an HttpChannelChild. I'm guessing this is probably too late to propagate the destruction back up to the parent.
Reporter | ||
Comment 5•8 years ago
|
||
Comment on attachment 8768147 [details]
stack of late HttpChannelChild destruction
Actually, seems like this is normal.
Attachment #8768147 -
Attachment is obsolete: true
Reporter | ||
Comment 6•8 years ago
|
||
Reporter | ||
Comment 7•8 years ago
|
||
(2 references leaked, both from nsCOMPtrs)
Reporter | ||
Comment 8•8 years ago
|
||
This HttpChannelChild never receives any messages, because...
Reporter | ||
Comment 9•8 years ago
|
||
The HttpChannelParent doesn't get created until XPCOM shutdown.
Comment 10•8 years ago
|
||
Ben, is this related to that other HTTPChannelChild (IIRC) bug you're working on?
Flags: needinfo?(bkelly)
Comment 11•8 years ago
|
||
(In reply to Andrew Overholt [:overholt] from comment #10) > Ben, is this related to that other HTTPChannelChild (IIRC) bug you're working on? (bug 1286258)
Comment 12•8 years ago
|
||
Its possible. David, can you try reproducing with a build before bug 1277582 comment 43 landed?
Flags: needinfo?(bkelly) → needinfo?(dbaron)
Comment 13•8 years ago
|
||
Oh, that landed after comment 0 here. So probably not related. Also, I don't see calendar.google.com running a service worker (at least for my account).
Flags: needinfo?(dbaron)
Updated•8 years ago
|
Priority: -- → P1
Updated•8 years ago
|
Whiteboard: [MemShrink]
Updated•8 years ago
|
Priority: P1 → P2
Updated•8 years ago
|
Whiteboard: [MemShrink] → [MemShrink:P2]
Updated•8 years ago
|
Flags: needinfo?(josh)
Updated•8 years ago
|
platform-rel: --- → ?
Whiteboard: [MemShrink:P2] → [MemShrink:P2][platform-rel-Google][platform-rel-GoogleCalendar]
Updated•8 years ago
|
platform-rel: ? → -
Comment 14•8 years ago
|
||
FWIW I couldn't reproduce this with 20161020074850 (nightly debug build) on Windows 10.
Comment 15•8 years ago
|
||
Two months ago I had no problems reproducing this leak. Now I cannot, nor could overholt. Any objection to closing this as WORKSFORME?
Reporter | ||
Comment 16•8 years ago
|
||
No, although it might be worth testing if it reproduces with a build from when it was filed to see whether it was a fix on our side or a change on the Google Calendar side.
Comment 17•8 years ago
|
||
I reverted to a revision from around when I last reproduced it, and I can no longer do so. I guess Google Calendar changed in ways that no longer trigger it.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(josh)
Resolution: --- → WORKSFORME
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•