Created attachment 131378 [details] Screenshot of what LO looked like as it crashed Since upgrading from LO 5.1.x to 5.2.5.1, I have had two hard crashes with a dialog pop-up that says std::bad_alloc. See attached screen shot. I had just typed Ctrl-Z, IIRC, while editing a comment. I'm pretty sure that's correct, looking at all the typos. Strangely, I have a crystal clear memory of fixing all those, just before it crashed, despite the evidence of the screenshot. In fact, I'm certain I fixed "cybered", "mage", "sort", "stimulant", "running", "and", "test", and was fixing something further down in the comment when I used Undo. I'd even added the text ";she's not a shape-shifter" and I think I had also reduced the comment's font size from 12 to 11. I'm 100% certain I made all those edits. Yet the screen snapshot doesn't agree! Could the screen buffer grabbed by the gnome screen shot be "out of date"?! (Taken from some un-refreshed back-buffer?) I have attached a (non-debug, sorry) gdb backtrace FWIW. (gdb) attach 32009 Attaching to process 32009 [New LWP 32010] [New LWP 32016] [New LWP 32017] [New LWP 32018] [New LWP 32030] [New LWP 32071] [New LWP 32643] [New LWP 425] [New LWP 2936] [New LWP 2937] [New LWP 2938] [New LWP 2939] where [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". warning: File "/opt/libreoffice5.2/program/libpython3.5m.so-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /opt/libreoffice5.2/program/libpython3.5m.so-gdb.py line to your configuration file "/root/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/root/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" 0x00007fb5af226b5d in poll () at ../sysdeps/unix/syscall-template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) where #0 0x00007fb5af226b5d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007fb5ad35738c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007fb5ad357712 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007fb59e0fdb83 in gtk_dialog_run () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #4 0x00007fb59e6cf88c in GtkSalSystem::ShowNativeDialog(rtl::OUString const&, rtl::OUString const&, std::list<rtl::OUString, std::allocator<rtl::OUString> > const&, int) () from /opt/libreoffice5.2/program/libvclplug_gtklo.so #5 0x00007fb5b22e9084 in SalGenericSystem::ShowNativeMessageBox(rtl::OUString const&, rtl::OUString const&) () from /opt/libreoffice5.2/program/libmergedlo.so #6 0x00007fb5b12f6fa4 in desktop::(anonymous namespace)::FatalError(rtl::OUString const&) () from /opt/libreoffice5.2/program/libmergedlo.so #7 0x00007fb5b1304d68 in desktop::Desktop::Main() () from /opt/libreoffice5.2/program/libmergedlo.so #8 0x00007fb5b2217c86 in ImplSVMain() () from /opt/libreoffice5.2/program/libmergedlo.so #9 0x00007fb5b2217d72 in SVMain() () from /opt/libreoffice5.2/program/libmergedlo.so #10 0x00007fb5b132748d in soffice_main () from /opt/libreoffice5.2/program/libmergedlo.so #11 0x000000000040075b in main () (gdb) detach Detaching from program: /opt/libreoffice5.2/program/soffice.bin, process 32009 (gdb) q It also crashed exactly the same way two days before, but this time while I was simply typing in new text. Note that LO is struggling with this file because the number of comments have grown. So sometimes I have to wait for what I type to appear. I don't know if that's relevant or not. It's the reason for all the typos: I was typing fast on this occasion, adding the comment, and typing blind, since I had to wait about 30 seconds for the text to appear. So then I started fixing it, and then... boom! This seems different, to me, from what is described in 95957. I have reopened the files and
Sorry, I confused myself by looking at the state of the comment in the file that LO recovered. Yes, all those edits (and more) are in place in the screen shot I've attached. I had somehow convinced myself I was looking at the screen shot rather than the recovered document window while I was completing the bug report. Please ignore my near-insane speculations about un-refreshed back-buffers. (How embarrassing!)
Continuing on re-doing the small amount of work lost when Writer crashed, I realise that I *had* finished editing the comment entirely and was simply editing the main body of the document when it crashed. I do think it was just after I'd used Undo, however.
Hello Luke, Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Since the bug seems to crash Writer only (!) about once per 12 hrs of use, it's not what I think you'd class as reproducible. I had hoped the partial backtrace and the knowledge it was caught by std::bad_alloc might be enough. I can make an obfuscated document, but if you have to edit it for several days, intensively, I don't see how that will really help you, unfortunately. So I'll leave this as NEEDINFO, since I know from what you've said below, that this report won't be enough for you to easily find the bug.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20170830
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20170929
FWIW, I had this happen again 2 days ago, running LO 5.2.6.2 on the same amd64 Ubuntu 16.04 Linux version. If I recall correctly, this time it happened after inserting a fresh table of contents and deleting the old one. I saved, and started editing and it crashed. But go ahead and resolve it as insufficient data if you wish, of course.
(In reply to Luke Kendall from comment #7) > FWIW, I had this happen again 2 days ago, running LO 5.2.6.2 on the same > amd64 Ubuntu 16.04 Linux version. > > If I recall correctly, this time it happened after inserting a fresh table > of contents and deleting the old one. I saved, and started editing and it > crashed. > > But go ahead and resolve it as insufficient data if you wish, of course. Hi Luke, this bug has been closed as RESOLVED INSUFFICENTDATA because without clear steps on how to reproduce it, there isn't much we can do. On the other hand, you can always reopen it if you find the way to reproduce the std::bad alloc problem, which will be fantastic.