If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

leaks after clicking on an event in google calendar

RESOLVED WORKSFORME

Status

()

Core
DOM
P2
normal
RESOLVED WORKSFORME
a year ago
a year ago

People

(Reporter: dbaron, Unassigned)

Tracking

({mlk})

Trunk
Points:
---

Firefox Tracking Flags

(platform-rel -, firefox50 affected)

Details

(Whiteboard: [MemShrink:P2][platform-rel-Google][platform-rel-GoogleCalendar])

Attachments

(6 attachments, 1 obsolete attachment)

(Reporter)

Description

a year ago
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

a year ago
Created attachment 8768133 [details]
child process XPCOM leak log
(Reporter)

Comment 2

a year ago
Created attachment 8768134 [details]
parent process XPCOM leak log
(Reporter)

Updated

a year ago
Attachment #8768133 - Attachment mime type: text/x-log → text/plain
(Reporter)

Comment 3

a year ago
(but sometimes the child process doesn't leak and only the parent process does)
(Reporter)

Comment 4

a year ago
Created attachment 8768147 [details]
stack of late HttpChannelChild destruction

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

a year 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

a year ago
Created attachment 8768163 [details]
stacks of the creation of 2 of the 3 leaked URLs in the child
(Reporter)

Comment 7

a year ago
Created attachment 8768165 [details]
explanation of the XMLHttpRequestMainThread in the child

(2 references leaked, both from nsCOMPtrs)
(Reporter)

Comment 8

a year ago
Created attachment 8768196 [details]
stack of HttpChannelChild creation

This HttpChannelChild never receives any messages, because...
(Reporter)

Comment 9

a year ago
Created attachment 8768197 [details]
stack of HttpChannelParent creation

The HttpChannelParent doesn't get created until XPCOM shutdown.
Ben, is this related to that other HTTPChannelChild (IIRC) bug you're working on?
Flags: needinfo?(bkelly)
(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)
Its possible.  David, can you try reproducing with a build before bug 1277582 comment 43 landed?
Flags: needinfo?(bkelly) → needinfo?(dbaron)
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)
Priority: -- → P1

Updated

a year ago
Whiteboard: [MemShrink]
Priority: P1 → P2
Whiteboard: [MemShrink] → [MemShrink:P2]

Updated

a year ago
Flags: needinfo?(josh)
platform-rel: --- → ?
Whiteboard: [MemShrink:P2] → [MemShrink:P2][platform-rel-Google][platform-rel-GoogleCalendar]
platform-rel: ? → -
FWIW I couldn't reproduce this with 20161020074850 (nightly debug build) on Windows 10.
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

a year 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.
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
Last Resolved: a year ago
Flags: needinfo?(josh)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.