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
And if you try a normal browser?
:-) 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.
[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 -
Created attachment 56276 [details] Test Kit See Comment 3
*** Bug 40980 has been marked as a duplicate of this bug. ***
*** Bug 41215 has been marked as a duplicate of this bug. ***
[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
@Rainer Bielefeld: My OS is Windows 7 Professional SP1. (Windows NT 6.1)
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.
(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.
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.
(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.).
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++
mpGlyphs2Chars = new int[ mnGlyphCapacity ]; I suppose, and I *guess* mnGlyphCapacity has ended up as a negative number or something ?
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).
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.
*** Bug 46838 has been marked as a duplicate of this bug. ***
Closing due to own results and comment
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.
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)?
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
@Nathan Wells: <http://wiki.documentfoundation.org/BugReport_Details#Version>
I guess getting a drmemory trace on windows (if we can keep it alive that long) may help us find the memory corruption (?)
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)
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.
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
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.
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.
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?
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.
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.
*** Bug 46053 has been marked as a duplicate of this bug. ***