Download it now!
Bug 45355 - CRASH if characters in text of BENGALI, TIBETAN, MALAYALAM, MARATHI, NEPALI, ORIYA, TAMIL, TELUGU, KHMER
Summary: CRASH if characters in text of BENGALI, TIBETAN, MALAYALAM, MARATHI, NEPALI, ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.6.0.0.beta2
Hardware: Other Windows (All)
: medium critical
Assignee: Not Assigned
URL:
Whiteboard: target:3.5.0 bibisected35 bibisected3...
Keywords: regression
: 40980 41215 46053 46838 (view as bug list)
Depends on:
Blocks: mab3.4 mab3.6
  Show dependency treegraph
 
Reported: 2012-01-28 17:16 UTC by Franz Gstättner
Modified: 2012-10-18 15:18 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Test Kit (17.98 KB, application/zip)
2012-01-29 01:52 UTC, Rainer Bielefeld Retired
Details
Calc Test (80.71 KB, image/png)
2012-07-08 12:17 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Franz Gstättner 2012-01-28 17:16:41 UTC
Problem description: 

Steps to reproduce:
1. Copy the whole wikitext (wikisyntax) from de.wikipedia article [[Homosexualität]]
2. Past it in Libre Writer
3. wait a little time

Current behavior: it crashes

Expected behavior: i can save the text

Platform (if different from the browser): 
              
Browser: Opera/9.80 (Windows NT 6.1; U; de) Presto/2.10.229 Version/11.61
Comment 1 Urmas 2012-01-28 22:56:14 UTC
And if you try a normal browser?
Comment 2 Franz Gstättner 2012-01-28 23:05:28 UTC
:-) Then it works.

I work on find a good solution to edit wikitext offline for saving locally, search & replace, etc. and i take this article as an example. And my Opera has now in the last 2 version a bug in find-function within formulars. And no browser has an replace.function.
Comment 3 Rainer Bielefeld Retired 2012-01-29 01:50:32 UTC
[Reproducible] with "LibreOffice 3.4.5 German UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit) 
Some further investigation showed that each of following text lines causes the crash:
[[bn:সমকামিতা]]
[[bo:མཚན་མཐུན་དགའ་རོགས་སྒྲིག་པ།]]
[[ml:സ്വവർഗ്ഗരതി]]
[[mr:समलैंगिकता]]
[[ne:समलिँगी]]
[[ta:தற்பால்சேர்க்கை]]
[[te:స్వలింగ సంపర్కం]]
[[th:รักร่วมเพศ]]
Also single words from the pages in that languages (i tested bn, bo) cause the crash.
Has nothing to do with wiki or copy paste, even a simple fileopen of a document containing listed strings causes the crash (see attached sample)
Also Calc is affected (see attached sample)!

Regression: no crash with "LibreOffice Portable 3.3.0  - WIN7  Home Premium (64bit) German UI [OOO330m19 (Build:6) tag libreoffice-3.3.0.4]" 

WORKSFORME with "LibreOffice 3.5.0 RC2 German UI/Locale [Build-ID: e371a95-bf68a13-5a1aa2b-d3c1ae9-b938258] on German WIN7 Home Premium (64bit) 

@Franz Gstättner, Urmas:
Your OS is?

@András:
It seems that LibO is currently not suitable for several Asian languages. So we should try to fix that also for 3.4.6.

I checked for TIBETAN UI and reproduced Bug 44208. Can you please check whether your fix (also for for Bug 45107) also covers languages in subject line (to be on the safe side)? With a little luck your fix also will fix this problem here (or can help to find how to solve this problem for 3.4)

- Reported with Bug Submission Assistant -
Comment 4 Rainer Bielefeld Retired 2012-01-29 01:52:22 UTC
Created attachment 56276 [details]
Test Kit

See Comment 3
Comment 5 Rainer Bielefeld Retired 2012-01-29 02:27:57 UTC
*** Bug 40980 has been marked as a duplicate of this bug. ***
Comment 6 Rainer Bielefeld Retired 2012-01-29 02:41:42 UTC
*** Bug 41215 has been marked as a duplicate of this bug. ***
Comment 7 Rainer Bielefeld Retired 2012-01-29 02:48:21 UTC
[Reproducible] with "LibreOffice 3.4.1RC1 - WIN7  Home Premium (64bit) German UI [OOO340m1 (Build:101)]", I am pretty sure that problem appeared with 3.4.0
Comment 8 Franz Gstättner 2012-01-29 07:32:55 UTC
@Rainer Bielefeld: My OS is Windows 7 Professional SP1. (Windows NT 6.1)
Comment 9 Caolán McNamara 2012-01-30 03:45:15 UTC
caolanm->timar: isn't this the windows bug that goes away with the better font-fallback reduced language tags ?

Though it'd still be nice to see a backtrace of the crash.
Comment 10 Andras Timar 2012-01-30 13:25:00 UTC
(In reply to comment #9)
> caolanm->timar: isn't this the windows bug that goes away with the better
> font-fallback reduced language tags ?
> 
> Though it'd still be nice to see a backtrace of the crash.

Yes, at least it is very similar. The problem here, that there is no entry for Tibetan in VCL.xcu, and Windows does not ship a good font for Tibetan either.
Comment 11 Caolán McNamara 2012-01-31 12:32:12 UTC
Vista comes with "Microsoft Himalaya", no ?

Either way, a backtrace of the crash might be useful to fix that as well as the other thread of improving the default font selection.
Comment 12 Andras Timar 2012-01-31 13:47:08 UTC
(In reply to comment #11)
> Vista comes with "Microsoft Himalaya", no ?

Yes. I checked XP first, then I found Microsoft Himalaya on Vista and Win7.

> 
> Either way, a backtrace of the crash might be useful to fix that as well as the
> other thread of improving the default font selection.

I'm building a debug build now. Any hints are welcome how to get a useable backtrace. It crashes with the doc recovery dialog (Due to an unepected error, LibreOffice crashed. All the files you were working on will now be saved. ... etc.).
Comment 13 Andras Timar 2012-02-01 13:09:14 UTC
Bug is reproducible with rc3, call stack is:

 	msvcr90.dll!std::bad_alloc::`vftable'()  + 0x5 bytes	C++
>	vcllo.dll!UniscribeLayout::Simplify(bool __formal=false)  Line 2107 + 0x17 bytes	C++
 	vcllo.dll!MultiSalLayout::AdjustLayout(ImplLayoutArgs & rArgs={...})  Line 1672 + 0x8 bytes	C++
 	vcllo.dll!OutputDevice::ImplLayout(const String & rOrigStr={...}, unsigned short nMinIndex=178, unsigned short nLen=27, const Point & rLogicalPos={...}, long nLogicalWidth=0, const long * pDXArray=0x00000000, bool bFilter=false)  Line 6070	C++
 	vcllo.dll!OutputDevice::GetTextBreak(const String & rStr={...}, long nTextWidth=3081, unsigned short nIndex=178, unsigned short nLen=27, long nCharExtra=0, unsigned char __formal='')  Line 6263 + 0x1f bytes	C++
Comment 14 Caolán McNamara 2012-02-02 00:36:24 UTC
mpGlyphs2Chars = new int[ mnGlyphCapacity ]; I suppose, and I *guess* mnGlyphCapacity has ended up as a negative number or something ?
Comment 15 Andras Timar 2012-02-02 01:02:32 UTC
I think the whole object was corrupted by then, because values of member variables were not available in debugger (CXX0030: Error: Expression cannot be evaluated).
Comment 16 panyazone 2012-03-04 18:20:48 UTC
I have reported Bug 46923, and was asked to take a look at this Bug 45355 whether they are related.

This Bug 45355 is on Writer, but Bug 46923 is on Calc. They are different.

I have tested this Bug 45355 with Writer LibreOffice 3.5.0 Released version on Windows 7 Professional by using the given Asian Language Strings in the bug report, one string at a time. 

First I copy one string and paste it on Writer. Nothing happen s for a while, then the cursor changes to waiting (round spinning) icon and Program Title bar show "(Not responding)" for about 30 seconds, then the LO is back to normal. LO does not crash. The text appeared in the first cell of the 1-row x 2-column table. If I paste a text as unformatted text, the program is perfectly normal.

Conclusion, this Bug 45355 is gone for LO 3.5.0.
Comment 17 Urmas 2012-03-09 13:01:45 UTC
*** Bug 46838 has been marked as a duplicate of this bug. ***
Comment 18 Rainer Bielefeld Retired 2012-03-20 09:53:55 UTC
Closing due to own results and comment
Comment 19 Nathan Wells 2012-07-05 21:00:58 UTC
In LibO 3.6.0.0.beta2 (Build ID: f010139) this issue occurs again (it was fixed in LibreOffice 3.5).

Just copy this:
ថិល-អឃោសៈ, សំ. បា. មាន​សូរ​ស័ព្ទ​ថា កៈ ។ ( ន. )
អវយវៈ​ដែល​ត​ពី​ក្បាល​ទៅ​ស្មា ឬ​ទៅ​ខ្លួន​នៃ​មនុស្ស​សត្វ ។ ដៃ​ជើង​មនុស្ស​ក៏​មាន
ក​ដែរ: ក​ដៃ​, ក​ជើង ។ ទង​ខាង​ដើម​កួរ​ស្រូវ​ក៏​ហៅ ក
and try to paste it into LibreOffice Writer 3.6.0.0.beta2 on Windows 7 64-bit - it will crash.
Comment 20 Rainer Bielefeld Retired 2012-07-05 22:33:15 UTC
Reappeared problem:
[Reproducible] with parallel installation of Master "LOdev " 3.7.0.0.alpha0+   - WIN7 Home Premium (64bit) ENGLISH UI [Build ID: c3dc9a3]" (tinderbox: 2008R2@20, pull time 2012-07-05 08:52:02)
[Reproducible] with Server Installation of  "LibreOffice 3.6.0.0.beta2  German UI/Locale [Build-ID: f010139] on German WIN7 Home Premium (64bit) 

So NEW for now although this problem might be completely different to the old one.

@Nathan Wells:
<https://wiki.documentfoundation.org/BugReport_Details#How_to_reopen_Bugs>
What indication do you have that it's really the same bug and not only similar symptoms?  

@Caolán McNamara
Can you please have a look (or forward to András)?
Comment 21 Rainer Bielefeld Retired 2012-07-05 22:42:33 UTC
Already [Reproducible] with 
parallel installation of MinGW Master "LibO-dev 3.5.0beta2+  – WIN7 Home Premium (64bit)  [Build ID: 18296b0-7f15fca-1fc8c06-ca8e46d] Win-x86@7-MinGW   pull time 2011-12-26 21:38:56  - tinderbox: git sha1s 
and
Server installation of MSVC Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) ENGLISH UI [Build ID:  a286353-090bcba-3bf3b94]" Win-x86@6 – 2011-12-02_22:36:35)

No crash, but unusable paste result with 3.5.5.3
Comment 22 Rainer Bielefeld Retired 2012-07-05 22:44:05 UTC
@Nathan Wells:
<http://wiki.documentfoundation.org/BugReport_Details#Version>
Comment 23 Michael Meeks 2012-07-06 02:43:49 UTC
I guess getting a drmemory trace on windows (if we can keep it alive that long) may help us find the memory corruption (?)
Comment 24 Julien Nabet 2012-07-08 12:17:47 UTC
Created attachment 63981 [details]
Calc Test

On pc Debian x86-64, with master sources updated today, I didn't reproduce crash with the ods or odt file contained in testKit.zip.
I attached the screenshot with an ods file.
(nothing special in logs too)
Comment 25 Caolán McNamara 2012-07-12 11:22:35 UTC
So... I can't get this to crash. But by fiddling around with the fonts under  Windows I did see some odd behaviour where the glyph replacement worked lovely  or some fonts but not for others. Debugging what I could see its plausible that  the crash is related to that.

This crash might only happen in glyph replacement where the font in use doesn't have certain glyphs, and a replacement font is found that does have them, but the replacement font is taller than the original and gets scaled down to fit the height of the original font.
Comment 26 Not Assigned 2012-07-12 12:32:58 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b3ec98dea6e59dcc0c94aeece0e4f8e35430a86a

Related: fdo#45355 stale gdi font handles apparently still used
Comment 27 Caolán McNamara 2012-07-12 12:39:14 UTC
I have high hopes for the above fix. 

But because I can't reproduce the crashes, e.g. of comment #19 I'd like if someone who can reproduce the crash could e.g. try tomorrow or so if the windows daily build from tomorrow or later no longer crashes, (http://dev-builds.libreoffice.org/daily/W2008R2@20-With-Symbol-Bytemark-Hosting/master/current/) and ideally if one if the earlier builds (http://dev-builds.libreoffice.org/daily/W2008R2@20-With-Symbol-Bytemark-Hosting/master/) does crash.
Comment 28 Nathan Wells 2012-07-13 14:23:03 UTC
I can confirm that (http://dev-builds.libreoffice.org/daily/W2008R2@20-With-Symbol-Bytemark-Hosting/master/current/) Version 3.7.0.0.alpha0+ (Build ID: d0e4215) no longer crashes when I copy and paste.
Comment 29 Nathan Wells 2012-07-14 11:57:04 UTC
Version 3.7.0.0.alpha0+ (Build ID: c3dc9a3) also works fine for me on Windows 7 64-bit.  How far back should I go?
Comment 30 Caolán McNamara 2012-07-14 12:19:43 UTC
d0e4215 is after my change, and c3dc9a3 is before it. That the latest one works "post-fix" is encouraging, that the older one works "pre-fix" as well is frustrating :-) I think its worth proposing the change for 3-6 despite the lack of conclusive evidence that it squashes this bug.
Comment 31 Not Assigned 2012-07-14 16:59:29 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c5df4ffdab3a66508b6e259703b77979a2733401&g=libreoffice-3-6

Related: fdo#45355 stale gdi font handles apparently still used


It will be available in LibreOffice 3.6.
Comment 32 Caolán McNamara 2012-10-18 15:18:41 UTC
*** Bug 46053 has been marked as a duplicate of this bug. ***