Issue 17727 - ~EntryList_Impl() trashing heap?
Summary: ~EntryList_Impl() trashing heap?
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 1.1 RC2
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: OOo 1.1.1
Assignee: fa
QA Contact: issues@framework
URL:
Keywords: crash, oooqa
Depends on:
Blocks:
 
Reported: 2003-07-31 17:58 UTC by dankegel
Modified: 2004-03-01 13:40 UTC (History)
5 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
cd sfx2, patch -p0 < /path/to/patchfile Cleans up EntryList_Impl naming & usage (17.73 KB, patch)
2004-02-06 06:55 UTC, fa
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description dankegel 2003-07-31 17:58:12 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).
Comment 1 dankegel 2003-07-31 17:59:40 UTC
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.
Comment 2 dankegel 2003-07-31 19:27:48 UTC
fixed summary...
Comment 3 kai.sommerfeld 2003-08-01 08:05:00 UTC
Hi Mathias,

Kay Ramme told me that you're volunteering to take care of this kind
of tasks. Handing it to you...
Comment 4 kai.sommerfeld 2003-08-01 08:05:57 UTC
.
Comment 5 kai.sommerfeld 2003-08-04 07:53:07 UTC
Resetting resolution, because there is no yet.
Comment 6 matthias.huetsch 2003-09-24 16:39:42 UTC
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
Comment 7 matthias.huetsch 2003-09-24 16:41:59 UTC
adding myself to CC...
Comment 8 jens-heiner.rechtien 2003-10-06 06:57:41 UTC
.
Comment 9 matthias.huetsch 2003-10-28 10:20:01 UTC
Removed nonsense dependency (issue 21786 depending on this one).
Comment 10 jens-heiner.rechtien 2004-01-27 09:50:18 UTC
move relaease target to OOo-2.0
Comment 11 fa 2004-02-06 06:54:00 UTC
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).
Comment 12 fa 2004-02-06 06:55:26 UTC
Created attachment 12919 [details]
cd sfx2, patch -p0 < /path/to/patchfile  Cleans up EntryList_Impl naming & usage
Comment 13 fa 2004-02-06 06:55:58 UTC
changing to Patch, and targetting for 1.1.1
Comment 14 Martin Hollmichel 2004-02-06 17:33:10 UTC
mh->mba: are you able to review ?
Comment 15 Mathias_Bauer 2004-02-13 16:22:30 UTC
Patch is approved.
I'm waiting for a CWS now.
Comment 16 Mathias_Bauer 2004-02-16 10:10:26 UTC
You can commit the patch in the next ooofix CWS.
Comment 17 jens-heiner.rechtien 2004-02-16 16:40:42 UTC
Fixed in CWS ooo111regression
Comment 18 jens-heiner.rechtien 2004-02-16 16:41:10 UTC
Verified.
Comment 19 jens-heiner.rechtien 2004-03-01 13:40:13 UTC
Closed.