Subject: Memory leaks according to Purify
From: Mike Nordell (tamlin@algonet.se)
Date: Wed Jun 20 2001 - 00:03:18 CDT
I was once again pretty close: It was mostly properties that leaked.
One of the allocating call-stacks are:
new(UINT) [new.cpp:23]
UT_String::UT_String(void) [ut_string_class.cpp:62]
UT_StringPtrMap::UT_StringPtrMap(UINT) [ut_hash.cpp:141]
PP_AttrProp::setProperty(char const*,char const*) [pp_AttrProp.cpp:266]
PP_AttrProp::setAttribute(char const*,char const*) [pp_AttrProp.cpp:225]
PP_AttrProp::setAttributes(char const* *) [pp_AttrProp.cpp:111]
pt_VarSet::storeAP(char const* *,UINT *) [pt_VarSet.cpp:121]
pt_PieceTable::_createBuiltinStyle(char const*,char const* *)
[pt_PT_Styles.cpp:125]
pt_PieceTable::_loadBuiltinStyles(void) [pt_PT_Styles.cpp:63]
pt_PieceTable::setPieceTableState(_PTState) [pt_PieceTable.cpp:71]
PD_Document::newDocument(void) [pd_Document.cpp:213]
AP_Win32Frame::_loadDocument(char const*,int) [ap_Win32Frame.cpp:1258]
There are also leaks from:
new(UINT) [new.cpp:23]
UT_Stringbuf::grow_common(UINT,bool) [ut_stringbuf.cpp:159]
UT_Stringbuf::grow_nocopy(UINT) [ut_stringbuf.cpp:144]
UT_Stringbuf::assign(char const*,UINT) [ut_stringbuf.cpp:82]
UT_Stringbuf::=(UT_Stringbuf const&) [ut_stringbuf.cpp:72]
UT_String::=(UT_String const&) [ut_string_class.cpp:126]
UT_StringPtrMap::insert(UT_String const&,void const*) [ut_hash.cpp:221]
UT_StringPtrMap::insert(char const*,void const*) [ut_hash.cpp:210]
UT_Xpm2Bmp(UINT,UINT,char const* *,UINT,HDC__ *,UT_RGBColor *,HBITMAP__
* *) [ut_Xpm2Bmp.cpp:124]
AP_Win32Toolbar_Icons::getBitmapForIcon(HWND__ *,UINT,UINT,UT_RGBColor
*,char const*,HBITMAP__ * *) [xap_Win32Toolbar_Icons.cpp:56]
EV_Win32Toolbar::synthesize(void) [ev_Win32Toolbar.cpp:634]
These are unfortunately currently _impossible_ to fix because of the current
(bad) design - the toolbar icons are never neither tracked nor free'd.
The m_hash in XAP_PrefsScheme (probably owned by AP_Win32Prefs) is probably
never released since its UT_StringMapPtr never release the ...
Hold it a moment...
Why does UT_StringPtrMap::insert(char const*,void const*) create _another_
UT_String?!
UT_StringPtrMap::insert can't really take a "const UT_string&" as its first
parameter, can it. it needs a _value_, not a reference to a value. That
function look dysfunctional to me.
Then we do have those strdup thingies I earlier accused:
calloc [dbgheap.c:456]
UT_strdup [ut_string.cpp:115]
XAP_PrefsScheme::setValue(char const*,char const*) [xap_Prefs.cpp:98]
AP_Win32Prefs::loadBuiltinPrefs(void) [ap_Win32Prefs.cpp:52]
AP_Prefs::fullInit(void) [ap_Prefs.cpp:66]
AP_Win32App::initialize(void) [ap_Win32App.cpp:124]
AP_Win32App::WinMain(char const*,HINSTANCE__ *,HINSTANCE__ *,char *,int)
[ap_Win32App.cpp:808]
Then we have the fun:
UT_Stringbuf::grow_common(UINT,bool) [ut_stringbuf.cpp:159]
UT_Stringbuf::grow_nocopy(UINT) [ut_stringbuf.cpp:144]
UT_Stringbuf::assign(char const*,UINT) [ut_stringbuf.cpp:82]
UT_Stringbuf::=(UT_Stringbuf const&) [ut_stringbuf.cpp:72]
UT_String::=(UT_String const&) [ut_string_class.cpp:126]
UT_StringPtrMap::insert(UT_String const&,void const*) [ut_hash.cpp:221]
UT_StringPtrMap::insert(char const*,void const*) [ut_hash.cpp:210]
PP_lookupProperty(char const*) [pp_Property.cpp:171]
PP_evalPropertyType(char const*,PP_AttrProp const*,PP_AttrProp
const*,PP_AttrProp const*,tProperty_type,PD_Document *,bool)
[pp_Property.cpp:343]
fl_BlockLayout::getPropertyType(char const*,tProperty_type,bool)const
[fl_BlockLayout.cpp:1426]
fl_BlockLayout::_lookupProperties(void) [fl_BlockLayout.cpp:441]
Well, that's a few, but enough to keep people occupied I believe? ;->
Cheers,
/Mike
This archive was generated by hypermail 2b25 : Wed Jun 20 2001 - 00:03:03 CDT