Crash during Traditional Chinese <-> Simplified Chinese conversion

Michael Stahl mstahl at redhat.com
Thu Jan 3 13:52:21 PST 2013


On 03/01/13 19:26, Matteo Casalin wrote:
> Hi all,
>      I've been lately struggling with crash in conversion from 
> Traditional to Simplified Chinese in Writer. After some debugging, I 
> tracked the problem to access to released memory, but I don't know ho to 
> proceed to solve the issue since it involves a deeper knowledge than I 
> have about Writer internal structure.
> I really would appreciate if anybody could give me any hint on this.
> Here are the details:
> The conversion is handled by editeng::HangulHanjaConversion class, which 
> is used as a base class for SwHHCWrapper (and is also derived in a 
> parallel manner also in editeng itself). Without digging into details 
> (the flow is quite convoluted), the problem arises in SwTxtNode::Convert 
> (sw/source/core/txtnode/txtedt.cxx) as follow:
> * line 1074: instantiate a SwLanguageIterator object, which builds a 
> list of pointers to non-copiable SwTxtAttr;
> * line 1111: call SetLanguageAndFont, which destroys the original 
> SwTxtAttr items which the iterator still points to;
> * line 1117: access the now deleted iterator items.

so SwTxtNode::SetLanguageAndFont calls InsertItemSet, with a
SvxFontItem, which will result in a RES_TXTATR_AUTOFMT hint... which may
be combined (in SwpHints::MergePortions) with an existing
RES_TXTATR_AUTOFMT that is adjacent to the insertion range (aCurPaM),
provided that the item set on the adjacent hint contains the same
attributes as the one on the insertion range.

SwTxtNode::Convert appears clearly wrong to me in modifying the hints of
a text node while iterating over them.  (it is possible that this used
to work in 2005 or earlier; i don't know if equal text hints were
combined before the introduction of AUTOFMT, as i wasn't around back then).

perhaps the insertion could be delayed until after the loop?



More information about the LibreOffice mailing list