Issue 5000 - SfxPoolItem 16bit reference count overflows
Summary: SfxPoolItem 16bit reference count overflows
Status: CLOSED FIXED
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 1.0.0
Hardware: PC Windows 2000
: P3 Trivial (vote)
Target Milestone: ---
Assignee: michael.ruess
QA Contact: issues@sw
URL:
Keywords: oooqa
: 3103 (view as issue list)
Depends on:
Blocks:
 
Reported: 2002-05-17 21:56 UTC by Unknown
Modified: 2013-08-07 14:43 UTC (History)
2 users (show)

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


Attachments
zipped doc file causing the error -content masked for confidentiality (532.79 KB, ZIP/winzip)
2002-05-17 22:19 UTC, Unknown
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Unknown 2002-05-17 21:56:34 UTC
Writer seems to be in a memory seeking loop opening a large Word document. 
After several minutes the programs invariably aborts with an error message. The 
system log shows exception c0000005 (at different addresses)  
[rtl_allocateMemory].

Other Word documents load just fine.  I can provide the document triggering the 
error, if needed.
Comment 1 Unknown 2002-05-17 22:19:24 UTC
Created attachment 1685 [details]
zipped doc file causing the error -content masked for confidentiality
Comment 2 Unknown 2002-05-20 17:23:10 UTC
Issue 5000 does not show as assigned. Trying to re-assigned. (hey, 
it's my first..)
Comment 3 prgmgr 2002-07-16 06:18:04 UTC
Thanks for posting Mario.

Duplicated on Win NT 4.0, OO 1.0.

OO 1.0 will start to load the file but eventually crashes with 
an "Unrecoverable error" dialog box.
Comment 4 stefan.baltzer 2002-11-26 17:09:54 UTC
Reassigned to Michael.
Comment 5 prgmgr 2002-11-26 19:52:05 UTC
Problem still exists in OOo 643c.
Comment 6 michael.ruess 2002-11-28 09:53:52 UTC
The document contains loads of tables. On import at approx. 75% you
get Assertions "AddRef: Referenzzaehler ueberschlaegt sich" and
"AddRed mit nicht-Pool-item". stack for this is below. After tons of
these two Assertions it crashes with a similar stack.
Is it really the filter or more an issue for MBA?

Stack:
SVL644MI! SfxPoolItem::AddRef(unsigned short) + 283 bytes
SVL644MI! SfxItemPool::Put(class SfxPoolItem const &,unsigned short) +
2324 bytes
SVL644MI! SfxItemSet::Put(class SfxPoolItem const &,unsigned short) +
1459 bytes
SVL644MI! SfxItemSet::Put(class SfxItemSet const &,unsigned char) +
330 bytes
SW644MI! SwCntntNode::SetAttr(class SfxItemSet const &) + 286 bytes
SW644MI! InsAttr(class SwDoc *,class SwPaM const &,class SfxItemSet
const &,unsigned short,class SwUndoAttr *) + 3892 bytes
SW644MI! SwDoc::Insert(class SwPaM const &,class SfxPoolItem const
&,unsigned short) + 271 bytes
SW644MI! SwFltControlStack::SetAttrInDoc(struct SwPosition const
&,class SwFltStackEntry *) + 2004 bytes
SW644MI! SwWW8FltControlStack::SetAttrInDoc(struct SwPosition const
&,class SwFltStackEntry *) + 126 bytes
SW644MI! SwFltControlStack::NewAttr(struct SwPosition const &,class
SfxPoolItem const &) + 123 bytes
SW644MI! SwWW8FltControlStack::NewAttr(struct SwPosition const &,class
SfxPoolItem const &) + 160 bytes
SW644MI! SwWW8ImplReader::NewAttr(class SfxPoolItem const &) + 279 bytes
SW644MI! SwWW8ImplReader::Read_Justify(unsigned short,unsigned char
const *,short) + 81 bytes
SW644MI! SwWW8ImplReader::ImportSprm(unsigned char const *,unsigned
short) + 104 bytes
SW644MI! SwWW8ImplReader::ReadTextAttr(long &,bool &) + 435 bytes
SW644MI! SwWW8ImplReader::ReadAttrs(long &,long &,bool &) + 35 bytes
SW644MI! SwWW8ImplReader::ReadText(long,long,short) + 427 bytes
Comment 7 caolanm 2002-11-28 15:54:09 UTC
cmc->mba:
Its not the filters fault as far as I can see, it's a big document
with huge amounts of the same hard coded up/down spacing on every
paragraph as well as vast uses of the same nonstyle left/right align
property on the contents of each cell. I believe that it is simply
that we are overflowing the reference count for a poolitem which is a
16bit value while I count approx 90,000+ instances of some of the
properties. If I disable the import of the overused properties then it
imports fine.
Comment 8 caolanm 2002-11-29 12:09:13 UTC
#105756# records another instance of this problem
Comment 9 Mathias_Bauer 2002-12-12 17:29:27 UTC
We can blow up the refcount of SfxPoolItem to 32 Bits.
For file format compatibility we store only 16 Bits in our binary 
format. Before we save, we check the ItemPool for RefCount overflow 
and deny saving if we detect one. If the application does not use the 
refcounts at all, we can avoid that. This must be checked by all 
modules that store an ItemPool.
Necessary changes:
Rename nRef and Method GetRef() in class SfxPoolItem, recompile all 
modules above SVTOOLS.
This will discover all usage of the RefCount.
All "special RefCounts" will be redefined.
Comment 10 Mathias_Bauer 2003-01-13 16:12:06 UTC
I fixed the RefCount problem, but I'm not able to detect if the 
import is done properly. I recommend to check this immediately if the 
RefCount fix is available that fixes the crash.

The RefCount fix will be available on all builds >=644.
Comment 11 Mathias_Bauer 2003-01-17 13:50:05 UTC
.
Comment 12 Mathias_Bauer 2003-01-17 17:48:48 UTC
Fixed in CWS CD5.
Comment 13 openoffice 2003-01-27 13:25:42 UTC
*** Issue 3103 has been marked as a duplicate of this issue. ***
Comment 14 Mathias_Bauer 2003-01-30 14:51:47 UTC
We now get many assertions in nonpro builds, this is fixed by CMC 
(#106844#).
Comment 15 Mathias_Bauer 2003-01-31 09:33:58 UTC
Reopened for QA
Comment 16 Mathias_Bauer 2003-01-31 09:35:04 UTC
@mru: please test this in CWS CD5.
Comment 17 michael.ruess 2003-02-03 08:57:10 UTC
Crash is fixed in internal workspace.
Comment 18 michael.ruess 2003-02-03 08:57:42 UTC
Fix will be public in OpenOffice 1.1 Beta.
Comment 19 michael.ruess 2003-02-13 16:25:33 UTC
Check fix with internal milestone.