Wer're trying to migrate our company from OpenOffice to LibreOffice for quite a while (i.e. since LibO exists) now because LibO has more pace and more desperately needed new features, but unfortunately every new version brings up a new blocker bug. Now it has bitten our main (huge) Business Planning sheet. In LibO 3.6.1 changing the value of any input cell takes ages (i.a. Minutes) to update the sheet (performance in OOo 3.4.1 is perfect in comparison) and since LibO 3.6.2 the document outright crashes LibO directly on load. Practical problem: Although I've "nulled" out all data in a copy in the sheet for debugging I don't feel like it's a good idea to publicly post our master business planning formulas here. Nevertheless I could send it via email to someone who's willing to debug the case (anonymous doesn't count as "someone" here ;) Anyone?
The more simple: remove any confidential data and send it but since you consider you can't... If in your company you have a workstation with Linux or use a Linux Livecd, you may retrieve an useful backtrace by following this link: http://wiki.documentfoundation.org/BugReport#How_to_get_backtrace_.28on_Linux.29 If you can't/don't want, I'm not a dev, just a simple contributor but I can retrieve a backtrace with symbols if you send the file to me. Rainer: if you have other ideas in cases like this, don't hesitate :)
Correct Version
@Nikolaus Kühn: Please send the confidential document to Julien or me. If we can reproduce the problem, we can try to create a sample document without confidential contents, or may be you can accept that additionally few developers will use the document for bugfixing (without publishing it).
@Juliun & Rainer: I just sent you the file - can't trace myself today because I'm leaving for a two week holidy. Thank you!
update: I found a minute to pull the libreoffice ppa including the -dbg packages into my ubuntu vm, but the ppa is only at 3.6.0 at the moment. Result: I cannot reproduce the crash, but I can reproduce the performance regression from 3.5.x: Before adding the ppa i was able to write the number 1 into cell "HeadcountDevelopment:P10" and got immediate update of the sheet. In 3.6.0 it takes ~ a minute until I can work with the sheet again. Separate Bug?
a wild guess: "Bug 55379 - FILEOPEN CRASH for particular .ods" sounds similar to this one concerning the characteristics of the documemt: - edited in many and varying old versions of LibO and OOo - large amounts of conditional formatting just a guess (not marking it as duplicate until verified)
Could you try on Windows after having renamed your LO profile? (see http://wiki.documentfoundation.org/UserProfile) If can't reproduce, could you zip and attach your LO profile?
I can still reproduce the bug after renaming my user profile (exact same behavior, crash at ca. 80% of the document loading progress bar in the bottom of the window)
Created attachment 68143 [details] bt on master On pc Debian x86-64 with master sources updated today (+ a brand new LO profile), I reproduced the bug so attached the bug.
Michael, JB: same backtrace than fdo#55617 (https://bugs.freedesktop.org/show_bug.cgi?id=55617) dup? Markus: would you have some time to take a look? We might kill 2 birds with one stone here
Sehr geehrte Damen und Herren, ich bin leider ab Samstag 06.10.2012 bis inklusive Donnerstag 18.10.2012 nicht erreichbar. Bitte wenden sie sich in zeitrkritischen Angelegenheiten an Frau Katrin Perry (perry@excentos.com) - sie kann sie an einen passenden Ansprechpartner weiterleiten. Mit freundlichen Grüßen, Nikolaus Kühn ------ Ladies and Gentlemen, I'm on holidays from Saturday 06th of October to (and including) Thursday 18th of October 2012. In time-critical issues please contact Katrin Perry (perry@excentos.com), she will be able to forward you to the best matching colleague. Best regards, Nikolaus Kühn
(In reply to comment #10) > Michael, JB: same backtrace than fdo#55617 > (https://bugs.freedesktop.org/show_bug.cgi?id=55617) dup? Not sure, I did my tests for fdo#55617 with the master, I did not found the same crash with LO 3.6.2.1 or even with LO 3.6.3.0+ before the backport of the commits fixing fdo#54940. I will try with LO 3.6.2.2. Best regards. JBF
[Reproducible] with reporter's confidential sample document and Server Installation of "LibreOffice 3.6.2.2 rc German UI/ German Locale [Build-ID: da8c1e6] on German WIN7 Home Premium (64bit) Worked fine with Server Installation of "LibreOffice 3.6.0.4 German UI/Locale [Build-ID: 932b512] on German WIN7 Home Premium (64bit) CRASH is still [Reproducible] with reporter's confidential sample document and Server Installation of "LibreOffice 3.6.3.0+ English UI/ German Locale [Build-ID: 1e73405] on German WIN7 Home Premium (64bit) {tinderbox: Win-x86@9, pull time 2012-10-05 15:31:15} Symptoms look similar to those in "Bug 55379 - FILEOPEN CRASH for particular .ods", but I can't tell whether backtraces underpin this suspect. Modified OS due to comment 9 I sent a sample document to Roman Eisele, may be he can confirm problem and create a backtrace for comparison with Bug 55379 @Markus: Please ask Julien for Sample document if he did not send already
Rainer: I haven't sent it to Markus for the moment. Nikolaus: I don't think there should be a problem but I prefer asking. Are you ok but may I send it?
(In reply to comment #12) > (In reply to comment #10) > > Michael, JB: same backtrace than fdo#55617 > > (https://bugs.freedesktop.org/show_bug.cgi?id=55617) dup? > > Not sure, I did my tests for fdo#55617 with the master, I did not found the > same crash with LO 3.6.2.1 or even with LO 3.6.3.0+ before the backport of > the commits fixing fdo#54940. I will try with LO 3.6.2.2. Test done: my bugdoc from bug 55617 (https://bugs.freedesktop.org/attachment.cgi?id=68075) does not crash LO 3.6.2.2 under Ubuntu 12.04 x86_64 Tested under valgrind. I will build master with Markus's patches related too CF committed last night and try again. Best regards. JBF
(In reply to comment #13) > I sent a sample document to Roman Eisele, may be he can confirm problem and > create a backtrace for comparison with Bug 55379 The crash is also REPRODUCIBLE on Mac OS X (10.6.8, Intel), with LibreOffice 3.6.2.2. The same symptoms: LibO crashes when the progress bar for the fileopen process is at ca. 75%. If I repeat the test and compare the log files, I get two slightly different types of log files: sometimes the first line of the stack trace reads 0 libsclo.dylib 0x21d65784 ScFormatEntry::operator==(ScFormatEntry const&) const + 20 and sometimes it reads just: 0 ??? 0000000000 0 + 0 but this is the only difference of both. I will attach the log file. It does only contain a simple stack trace without full symbols, but at least this will be sufficient for comparison with other bugs. Changing Platform again to “All” (please do not change it again back to “Windows” ;-), this is definitely a cross-platform issue).
Created attachment 68163 [details] Mac OS X (10.6.8, x86) log file for bug 55633, LibO 3.6.2.2
Created attachment 68164 [details] Mac OS X log file for bug 55633, LOdev 3.7.0 2012-10-04 The document also still crashes on fileopen with LOdev 3.7.0.0.alpha0+ (Build ID: dd11a1e; pull time: 2012-10-04 12:52:50) on the same machine. The (simple) stack trace is nearly identical; little difference in line 14: “XML_ParseBuffer_UTF16” instead of “XML_ParseBuffer”. So this crash is NOT fixed by the fix for bug 55379.
(In reply to comment #18) > Created attachment 68164 [details] > Mac OS X log file for bug 55633, LOdev 3.7.0 2012-10-04 > > The document also still crashes on fileopen with LOdev 3.7.0.0.alpha0+ > (Build ID: dd11a1e; pull time: 2012-10-04 12:52:50) on the same machine. The > (simple) stack trace is nearly identical; little difference in line 14: > “XML_ParseBuffer_UTF16” instead of “XML_ParseBuffer”. > > So this crash is NOT fixed by the fix for bug 55379. Hi Roman, Markus commited several new patches related to conditional formatting last night (the last is http://cgit.freedesktop.org/libreoffice/core/commit/?id=c6e44b87ef6d47ab24bebd586de3e75e9f08cfbe). These patches do not fix the crash of bug 55617 but perhaps this one. I do not have the file to do the test myself. Best regards. JBF
None of my patches will fix any crashes that have been in before my patch set. These were only patches to the dialogs and to the way we store conditional format information in cells. I will have a look at these problems with old style cond formats in some days.
Because of the identical stack traces I assume this is the same bug as 55379, just as Rainer Bielefeld suggested (comment #13). Therefore I mark this as a duplicate of 55379. Feel free to REOPEN this issue if you come to a different judgement (I have got a cold and am making many mistakes today ;-). *** This bug has been marked as a duplicate of bug 55379 ***
Works fine with Server Installation of "LibreOffice 3.6.4.0+ English UI/ German Locale [Build-ID: a4b919d],{tinderbox: Win-x86@9 pull time 2012-10-10 19:11:32} on German WIN7 Home Premium (64bit). I worked on sample documents for crashes with that Version 1/2 hour intensively without bigger problems. But reporter's confidential sample document is really hard work for LibO, I jumped thorugh the document aimless and deleted some rows or columns, and often LibO stopped responding for 15s or so. @Nikolaus Kühn Please submit a new Bug if this "stops responding temporarily" problem is new with latest versions.
Hi everyone, thanks a lot for digging through this mess of a bug - I have just installed the official 3.6.3 release on my WinVista64 Core2Duo and the good news is that I cannot reliably reproduce the crash on startup now (tried seven times in various ways). Nevertheless I had a random crash on one of the tries, but I can't reproduce that now. The "does not respond upon changes in the document" issue has improved massively but is still there: - changing a cell that has a lot of impact (e.g. "Scenarios:P1" from "1" to "3") blocks the UI for ~15 seconds (It was 2-3 Minutes in 3.6.2, but takes less than a second in OOo 3.4.1) - changing a cell that has not so much impact is much slower (2-3 seconds on the first change, less than a second on subsequent changes) @Rainer Bielefeld: I suspect this should be a separate Issue - can you reproduce the performance Issue?