Created attachment 167567 [details] gdbtrace.log In a corporate environment I tried to open an .xlsx file where libreoffice complained about the problem reported with bug 50916. After I enabled experimental feature support and support for very large tables, LO now crashes when opening the same file. Following the hints of the mentioned bug to track this problem, I received a first trace with localc --backtrace <file> Since the crash was caused by a termination signal indicating a C++ exception, I followed the hints for catching exceptions and got an additional trace, which is also attached. Unfortunately I cannot attach the file in question here for data protection reasons. But I can do further tests if that helps. I could also build and test a local version of libreoffice 7.0.1.3 using https://build.opensuse.org/package/show/LibreOffice:7.0/libreoffice.
Created attachment 167568 [details] libreoffice-c++-exception-backtrace.log
Michael: thought you might be interested in the traces showing QT part.
(In reply to Ralf Habacker from comment #0) > After I enabled experimental feature support and support for very large > tables, LO now crashes when opening the same file. Looking at the backtraces, I'm wondering whether those problems are directly related to the file or rather other features that were enabled as well by the "experimental" switch. (The second bt e.g. looks related to extension manager.) Does everything work reproducibly as expected if you use a different file (and reliably produce the same backtraces when you use the problematic file)? > Following the hints of the mentioned bug to track this problem, I received a > first trace with > > localc --backtrace <file> > > Since the crash was caused by a termination signal indicating a C++ > exception, I followed the hints for catching exceptions and got an > additional trace, which is also attached. Out of curiosity: Where do I find those hints? > Unfortunately I cannot attach the file in question here for data protection > reasons. But I can do further tests if that helps. I could also build and > test a local version of libreoffice 7.0.1.3 using > https://build.opensuse.org/package/show/LibreOffice:7.0/libreoffice. Having a way to reproduce a crash makes it much more likely that somebody will be able to find (and fix) the underlying issue, so it'd be great if you could find a way to either remove non-public information or create a new file that shows the same issue. What I usually do to find out what causes such problems is to create a copy of the problematic file and then delete content until the problem disappears, to strip the file down to the relevant part (which also often makes it possible to create a new file that has the same relevant characteristic to trigger the problem). (I probably won't be able to help much with the issue concerning large tables itself, but suppose that it's currently experimental for a reason.)
(In reply to Michael Weghorn from comment #3) Thanks for answering. > Out of curiosity: Where do I find those hints? > > > Unfortunately I cannot attach the file in question here for data protection > > reasons. But I can do further tests if that helps. I could also build and > > test a local version of libreoffice 7.0.1.3 using > > https://build.opensuse.org/package/show/LibreOffice:7.0/libreoffice. At the top of attachment 167568 [details]
(In reply to Ralf Habacker from comment #4) > At the top of attachment 167568 [details] Thanks. Are those steps recommended somewhere in our wiki (or elsewhere) for "advanced bug reporters" or so? (It's the first time I hear about this. :) )
(In reply to Michael Weghorn from comment #5) > Thanks. Are those steps recommended somewhere in our wiki (or elsewhere) for > "advanced bug reporters" or so? (It's the first time I hear about this. :) ) I don't remember exactly on which bug I found that info. I started with bug 133619 and iterated through the bugs listed at the "depends on" list.
(In reply to Ralf Habacker from comment #6) > (In reply to Michael Weghorn from comment #5) > > > Thanks. Are those steps recommended somewhere in our wiki (or elsewhere) for > > "advanced bug reporters" or so? (It's the first time I hear about this. :) ) > > I don't remember exactly on which bug I found that info. I started with bug > 133619 and iterated through the bugs listed at the "depends on" list. Just saw that the mentioned bug was for regressions using normal sized tables, bug 133764 is for issues with big tables.
(In reply to Michael Weghorn from comment #5) > Thanks. Are those steps recommended somewhere in our wiki (or elsewhere) for > "advanced bug reporters" or so? (It's the first time I hear about this. :) ) A few more details: 1. The file gdbtrace.log has been generated by following https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace 2. In the gdbtrace.log there is: Thread 1 "soffice.bin" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 } #0 0x00007ffff3e4c520 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ffff3e4db01 in __GI_abort () at abort.c:79 #2 0x00007ffff696b430 in Scheduler::CallbackTaskScheduling() () at /usr/lib64/libreoffice/program/libmergedlo.so After searching for Scheduler::CallbackTaskScheduling I found https://bugs.documentfoundation.org/show_bug.cgi?id=113284 where catching exceptions is mentioned. This is the same procedure as mentioned at https://wiki.documentfoundation.org/Development/How_to_debug#Finding_a_stacktrace_of_an_.22ignored.22_C.2B.2B_exception for lldb. The whole procedure then is: (gdb) b Scheduler::CallbackTaskScheduling() r (gdb) set pagination off (gdb) catch throw Catchpoint 2 (throw) (gdb) command 2 Type commands for breakpoint(s) 2, one per line. End with a line saying just "end". >bt >c >end (gdb) set logging file /tmp/localc-crash.log (gdb) set logging redirect on (gdb) set logging on
Created attachment 167595 [details] log files with all throwed exceptions The attachment with two log files contains all throwed exceptions - localc-10000.ods.log is from https://bugs.documentfoundation.org/attachment.cgi?id=151048 - localc-crash.xlsx.log from the crashing file
Created attachment 167596 [details] log file showing numbers of occured exceptions (update 1)
Created attachment 167597 [details] Grouped and sorted list of esceptions > 508 #1 0x00007fffb77b24a1 in ScCellRangeObj::GetCellByPosition_Impl(int, int) () at /usr/lib64/libreoffice/program/../program/libsclo.so This exception happens much more often than others
[Automated Action] NeedInfo-To-Unconfirmed
Can you test with a daily build of current the current development branch (master) and create a "normal" backtrace with that one? Daily debug builds are available at [1] https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@86-TDF-dbg/
Created attachment 167721 [details] gdbtrace.log (2020-12-01_05.09.39) (In reply to Michael Weghorn from comment #13) > Can you test with a daily build of current the current development branch > (master) With the build from https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@86-TDF-dbg/2020-12-01_05.09.39/ soffice does not crash after big tables suppor enabled but it needs much more time to load that file: without big table support: 8 sec (including click on warning checkbox) with big table support: 23 sec > and create a "normal" backtrace with that one? has been appended
(In reply to Ralf Habacker from comment #14) > With the build from > https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@86-TDF- > dbg/2020-12-01_05.09.39/ soffice does not crash after big tables suppor > enabled Thanks a lot for testing. Since it seems to be fixed in the current development version already, can we close this bug as WORKSFORME? > but it needs much more time to load that file: > > without big table support: 8 sec (including click on warning checkbox) > with big table support: 23 sec I'm not familiar with jumbo sheet support and whether any such behaviour is to be expected. In any case, it's different from the original problem, so I suggest to create a separate bug report if that should be investigated further.
Seems to be fixed in 7.2.0.0 alpha0 release.