Closed
Bug 408601
Opened 17 years ago
Closed 8 years ago
Adding a Exception for SSL Sites leaks nsGlobalWindow
Categories
(Core Graveyard :: Security: UI, defect, P4)
Core Graveyard
Security: UI
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: cbook, Unassigned)
References
Details
(Keywords: memory-leak)
Attachments
(3 files)
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?
|
||
Comment 1•17 years ago
|
||
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
|
|
||
Comment 3•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
Summary: Adding a Exception for SSL Sites leaks → Adding a Exception for SSL Sites leaks nsGlobalWindow
|
||
Comment 5•17 years ago
|
||
Yep, gotta fix. +'ing w/ P3 priority.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
|
||
Comment 6•17 years ago
|
||
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•17 years ago
|
Attachment #295994 -
Attachment mime type: text/x-log → text/plain
|
|
Reporter | |
Comment 7•17 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•17 years ago
|
||
Also filed now Bug 411743 for the crash on the steps to reproduce
Priority: P3 → P4
I think P4 is enough here since this is probably a pretty rare operation.
|
||
Updated•17 years ago
|
Flags: tracking1.9+ → wanted-next+
This appears to have been fixed somewhere along the line.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
|
Assignee | |
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•