Apache OpenOffice (AOO) Bugzilla – Issue 17727
~EntryList_Impl() trashing heap?
Last modified: 2004-03-01 13:40:13 UTC
Splitting this issue off from issue 8492 as requested by Kai. May well be related to issue 17725, which is another error (pthread_mutex_destroy: mutex is still in use) reported about the same time under this scenario. Julian's report, lightly edited: Valgrind showed a couple of invalid writes which may have trashed the heap. These happen soon after the "Initializing templates for first time use" box comes up. These writes happen at inivctl1.cxx:4192, which is EntryList_Impl::~EntryList_Impl() { _pOwner->pHead = 0; // line 4192 } This is for OOo 1.1RC2. A log is at http://www.openoffice.org/issues/showattachment.cgi?attach_id=8130 from issue 8492. FWIW valgrind shows very few invalid writes in OOo, so this might be worth looking into. To reproduce: (see also http://kegel.com/openoffice/#valgrind) Build 1.1rc2 with -g and (importantly) alloc.c (somewhere in sal/) with -DFORCE_SYSALLOC=1 (check in alloc.c for the exact spelling of this macro name). Build valgrind-20030725. Do whatever you have to do so that when OOo is started and you go to the autopilot, you will get the 'Initializing templates for first time use" box. Start oo like this (or equivalent, this is what I do) valgrind -v --trace-children=yes --num-callers=20 --freelist-vol=20000000 /path/to/soffice. I usually use /usr/bin/script to capture the huge amount of text V spews out. Do stuff with OOo so said dialog box appears. After it appears, cancel and exit OOo. Somewhere amongst the huge number of complaints about uninitialised value use, you should find two errors of the form "Invalid write of size 4". (Search for the text "Invalid"). This is what you are after. (The uninit stuff should be fixed too, at some stage).
Adding keyword "crash" because this is the kind of bug that is likely to cause a crash on some systems. adding cc: sewardj. I set target to 1.1.1 though I'd much prefer to see this fixed in 1.1, as I have a feeling the OpenOffice folks do not yet take this kind of error seriously enough to try to fix it in the weeks remaining before 1.1.
fixed summary...
Hi Mathias, Kay Ramme told me that you're volunteering to take care of this kind of tasks. Handing it to you...
.
Resetting resolution, because there is no yet.
Even though the stack provided in the attachment to issue 8492 looks strange at first glance (call from ~GroupData_Impl() in sfx to ~EntryList_Impl in svtools), this may well be true (and wrong) and thus valgrind's complaints may be correct. As shown below, libsvt...so does indeed export a *global* symbol "__1cOEntryList_Impl2T6M_v_", ~EntryList_Impl(), while libsfx...so defines two *local* symbols of the same name. AFAIK, the runtime linkers symbol resolution rules will satisfy all references to ~EntryList_Impl() in sfx with the global definition of this symbol in svtools, and not with the local definitions within sfx. .../svtools 238 % nm -D unxsols4.pro/lib/libsvt645ss.so | grep EntryList_Impl [1338] | 4176280| 32|FUNC |GLOB |0 |8 |__1cOEntryList_Impl2T5B6M_v_ [13680] | 4176180| 48|FUNC |GLOB |0 |8 |__1cOEntryList_Impl2t5B6MpnWSvxIconChoiceCtrl_Impl_HH_v_ [2452] | 4176228| 52|FUNC |GLOB |0 |8 |__1cOEntryList_Impl2t5B6MpnWSvxIconChoiceCtrl_Impl_HHH_v_ [2723] | 4176280| 32|FUNC |GLOB |0 |8 |__1cOEntryList_Impl2T6M_v_ [9962] | 4176180| 48|FUNC |GLOB |0 |8 |__1cOEntryList_Impl2t6MpnWSvxIconChoiceCtrl_Impl_HH_v_ [17492] | 4176228| 52|FUNC |GLOB |0 |8 |__1cOEntryList_Impl2t6MpnWSvxIconChoiceCtrl_Impl_HHH_v_ [16151] | 4176312| 32|FUNC |GLOB |0 |8 |__1cOEntryList_ImplFClear6M_v_ [8326] | 4176344| 76|FUNC |GLOB |0 |8 |__1cOEntryList_ImplGInsert6MpnWSvxIconChoiceCtrlEntry_L_v_ [1793] | 4176420| 40|FUNC |GLOB |0 |8 |__1cOEntryList_ImplGRemove6ML_pnWSvxIconChoiceCtrlEntry__ [5942] | 4176460| 48|FUNC |GLOB |0 |8 |__1cOEntryList_ImplGRemove6MpnWSvxIconChoiceCtrlEntry__v_ [12838] | 4176508| 100|FUNC |GLOB |0 |8 |__1cOEntryList_ImplMRemoved_Impl6MpnWSvxIconChoiceCtrlEntry__v_ .../svtools 240 % nm ../sfx2/unxsols4.pro/lib/libsfx645ss.so | grep EntryList_Impl [5203] | 2390488| 20|FUNC |LOCL |0 |8 |__1cOEntryList_Impl2T6M_v_ [5009] | 2340624| 20|FUNC |LOCL |0 |8 |__1cOEntryList_Impl2T6M_v_ .../svtools 241 % cd ../sfx2/ .../sfx2 242 % find . -name "*.?xx" -exec grep EntryList_Impl {} /dev/null \; ./source/doc/doctemplates.cxx:DECLARE_LIST( EntryList_Impl, EntryData_Impl* ); ./source/doc/doctemplates.cxx: EntryList_Impl maEntries; ./source/doc/doctempl.cxx:DECLARE_LIST( EntryList_Impl, EntryData_Impl* ); ./source/doc/doctempl.cxx: EntryList_Impl maEntries; That's what I have so far. Heiner, can you please have a look into this (during your other valgrind cleanup work)? Thanks, Matthias
adding myself to CC...
Removed nonsense dependency (issue 21786 depending on this one).
move relaease target to OOo-2.0
For whatever reason, this is causing the OS X linker to bail out on sfx2 module on OS X. We need this fixed now and now in 2.0. Patch attached, renames the distinct uses of EntryList_Impl in sfx2 to be specific to their particular file (doctmpl.cxx, doctemplates.cxx).
Created attachment 12919 [details] cd sfx2, patch -p0 < /path/to/patchfile Cleans up EntryList_Impl naming & usage
changing to Patch, and targetting for 1.1.1
mh->mba: are you able to review ?
Patch is approved. I'm waiting for a CWS now.
You can commit the patch in the next ooofix CWS.
Fixed in CWS ooo111regression
Verified.
Closed.