On 01/04/2013 01:07 PM, Matteo Casalin wrote:
Hi Michael,
On 01/03/2013 10:52 PM, Michael Stahl wrote:
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?
Thanks for the detailed reply - unluckily I have no skills in Writer and
its internals yet, so I do not understand the implications of the
AUTOFMT attribute. By looking at the code, my understanding of what
needs to be done in order to postpone the insertion is:
* iterate over attributes in order to find the portion with the desired
language, without inserting new properties;
* save the information about that portion;
* if necessary, re-iterate over the attributes with SetLanguageAndFont
Obviously, this would not work since we will get the same issue on the
second loop. Instead we can push PaM information (on which to
SetFontAndLanguage) in a queue and then iterate on it after the main
loop is completed. I'll start working on a patch and see what happens
with the Chinese document I have available. If that works, I'll submit
the patch to gerrit, hoping that someone could also apply broader tests
on the results (I don't have any knowledge of Chinese).
* return the previously saved information;
This could be done only if properties that are inserted do not influence
the search of the language in the first iterations or corrupt the saved
information.
Could this work? I really would like to fix the bug, but fear to break
something else.
Thanks again!
Cheers
Matteo
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
