Closed Bug 10828 Opened 25 years ago Closed 25 years ago

MLK:28 bytes leaked nsFileSpecImpl from sPref::useDefaultPrefFile()

Categories

(Core :: Preferences: Backend, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: bruce, Assigned: neeti)

References

Details

July 28, 1999 build on Solaris 2.6 with gcc 2.7.2.  Ran viewer and only loaded
about:blank

MLK: 28 bytes leaked at 0x23ccd8
  * This memory was allocated from:
        malloc         [rtlib.o]
        __bUiLtIn_nEw  [libgcc.a]
        __builtin_new  [rtlib.o]
        nsFileSpecImpl::Create(nsISupports*,const nsID&,void**)
[nsFileSpecImpl.cpp:729]
        nsGenericFactory::CreateInstance(nsISupports*,const nsID&,void**)
[nsGenericFactory.cpp:53]
        nsComponentManagerImpl::CreateInstance(const nsID&,nsISupports*,const
nsID&,void**) [nsComponentManager.cpp:1277]
        nsComponentManagerImpl::CreateInstance(const char*,nsISupports*,const
nsID&,void**) [nsComponentManager.cpp:1310]
        nsComponentManager::CreateInstance(const char*,nsISupports*,const
nsID&,void**) [nsRepository.cpp:79]
        nsPref::useDefaultPrefFile() [nsPref.cpp:279]
        nsPref::ReadUserPrefs() [nsPref.cpp:454]
        nsViewerApp::Initialize(int,char**) [nsViewerApp.cpp:260]
        main           [nsGTKMain.cpp:88]
        _start         [crt1.o]
Assignee: mcmullen → don
Don, let me know who you want to be default engineer for this component.
Warren fixed this one I think with his checkin for version 3.55 of nsPref.cpp
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
marking resolved and verified then, per reporter
Status: VERIFIED → REOPENED
I used the term 'I think' .. I wasn't sure. and now I see that warren reverted
his change.  Patience!
Resolution: FIXED → ---
k, I'll take a deep breath
My change seemed to be getting rid of the leaking file spec too early and was
causing a crash on linux for some reason. I didn't see it on windows. So we
should keep this bug open, and try another fix. Maybe the file spec needs to be
released in some prefs shutdown code (which may or may not exist -- I'll have
to check).
Assignee: don → dp
Status: REOPENED → NEW
Assignee: dp → dougt
Assignee: dougt → neeti
assigning to libpref owner.
Status: NEW → ASSIGNED
Target Milestone: M11
Summary: MLK: nsFileSpecImpl from sPref::useDefaultPrefFile() → MLK:28 bytes leaked nsFileSpecImpl from sPref::useDefaultPrefFile()
Blocks: 14516
Target Milestone: M11 → M12
Target Milestone: M12 → M13
I just checked for leaks of nsFileSpecImpl, and found two types of them:

1. Leaked from cookie code.  I have a fix, pending a review.
2. In some debug-only code in nsBaseWidget.cpp.

I would say it's probably fine to close this bug after I check in my fix, unless
someone wants to help clean up the widget code.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
This was fixed by bryner@uuic.edu fix in mozilla/extensions/cookie/nsCookie.cpp.
Status: RESOLVED → VERIFIED
marking verified
Moving all libPref component bugs to new Preferences: Backend component.  
libPref component will be deleted.
Component: libPref → Preferences: Backend
You need to log in before you can comment on or make changes to this bug.