Adding a Exception for SSL Sites leaks nsGlobalWindow

RESOLVED WORKSFORME

Status

P4
normal
RESOLVED WORKSFORME
11 years ago
2 years ago

People

(Reporter: cbook, Unassigned)

Tracking

({memory-leak})

Trunk
memory-leak
Dependency tree / graph
Bug Flags:
wanted-next +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

11 years ago
Created attachment 293425 [details]
leak log

Build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre)
Gecko/2007121517 Minefield/3.0b3pre

Steps to reproduce:
- Go to https://verisign.com
- Add a expection for the Site
- The verisign homepage loads
-> Assertion

nsStringStats
 => mAllocCount:          35740
 => mReallocCount:         4846
 => mFreeCount:           35010  --  LEAKED 730 !!!
 => mShareCount:          36695
 => mAdoptCount:           5995
 => mAdoptFreeCount:       5988  --  LEAKED 7 !!!
Flags: blocking-firefox3?
This is not identical to bug 402479, but as with that one, I strongly suspect the leak comes from the notification callback code here:

http://mxr.mozilla.org/mozilla/source/security/manager/pki/resources/content/exceptionDialog.js#150

Since this is happening in PSM code, moving components - that will clear the blocking nom, so I'll re-nom on the other side.
Assignee: nobody → kengert
Component: Security → Security: UI
Flags: blocking-firefox3?
OS: Windows XP → All
Product: Firefox → Core
QA Contact: firefox → ui
Hardware: PC → All
Restoring tomcat's nom after moving components.
Flags: blocking1.9?
Tomcat - can you still reproduce this on trunk?  Bug 158066 landed yesterday which seems like it might have fixed the problem in bug 402479, and I wonder if it fixes this one too?
(Reporter)

Comment 4

11 years ago
Created attachment 293876 [details]
new leak log

Johnathan, it still leaks with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007121916 Minefield/3.0b3pre

Updated

11 years ago
Summary: Adding a Exception for SSL Sites leaks → Adding a Exception for SSL Sites leaks nsGlobalWindow
Yep, gotta fix.  +'ing w/ P3 priority.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3

Comment 6

11 years ago
Created attachment 295994 [details]
stack

I get a crash when following the steps to reproduce.
Also assertions:
###!!! ASSERTION: nsStreamLoader not thread-safe: '_mOwningThread.GetThread() == PR_GetCurrentThread()', file /home/smaug/mozilla/mozilla_cvs/mozilla/netwerk/base/src/nsStreamLoader.cpp, line 65

Updated

11 years ago
Attachment #295994 - Attachment mime type: text/x-log → text/plain
(Reporter)

Comment 7

11 years ago
(In reply to comment #6)
> Also assertions:
> ###!!! ASSERTION: nsStreamLoader not thread-safe: '_mOwningThread.GetThread()
> == PR_GetCurrentThread()', file
> /home/smaug/mozilla/mozilla_cvs/mozilla/netwerk/base/src/nsStreamLoader.cpp,
> line 65
> 

i guess thats Bug 350873
(Reporter)

Comment 8

11 years ago
Also filed now Bug 411743 for the crash on the steps to reproduce

Updated

11 years ago
Blocks: 411743
I think P4 is enough here since this is probably a pretty rare operation.
Flags: tracking1.9+ → wanted-next+

Comment 10

6 years ago
reassign bug owner.
mass-update-kaie-20120918
Assignee: kaie → nobody
This appears to have been fixed somewhere along the line.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
(Assignee)

Updated

2 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.