Created attachment 123439 [details] A document for test I tried to open the file attached with LO 5.0.5.2 on Windows 7 and I and ended with a fatal error : Bad allocation.
Created attachment 123440 [details] screenshot of bad allocation error
At the same time the ".~lock.test.ods#" file is not deleted after you close the error message.
No problem. Does it happen with 5.1? 64-bit, KDE Plasma 5 Build ID: 5.1.0.3 Arch Linux build-1 CPU Threads: 8; OS Version: Linux 4.4; UI Render: default; Locale: fi-FI (fi_FI.UTF-8)
Created attachment 123448 [details] screenshot of bad allocation error with LO 5.1 Yes, same error and same lock file with version 5.1.
Maybe you could get a bt: https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg
Repro with Version: 5.2.0.0.alpha0+ Build ID: 98a8eafa915b8d57b8bdccab9981e537d77f6f4a CPU Threads: 1; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-02-25_00:49:33 no repro : 5.1.0.3 (x64)
My version : Version: 5.1.0.3 Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Locale : fr-FR (fr_FR)
Created attachment 123449 [details] backtrace_lo_5.1.0.3
(In reply to Stéphane Aulery from comment #8) > Created attachment 123449 [details] > backtrace_lo_5.1.0.3 It seems the trace was not successful.
I suspected a little. I try launching Calc with a new document before I open the fatal file!
Created attachment 123450 [details] backtrace_lo_5.1.0.3_v2
WinDbg is not cooperative : ************* Symbol Path validation summary ************** Response Time (ms) Location Deferred CACHE*C:\symbols Deferred SRV*http://dev-downloads.libreoffice.org/symstore/symbols Deferred SRV*http://msdl.microsoft.com/download/symbols 0:000> !analyze -v ERROR: FindPlugIns 8007007b ERROR: Some plugins may not be available [8007007b] ******************************************************************************* * * * Exception Analysis * * * ******************************************************************************* ***** OS symbols are WRONG. Please fix symbols to do analysis. ***** OS (WOW64 kernel32) symbols are WRONG. Please fix symbols to do analysis.
Created attachment 123452 [details] soffice.bin_160309_222133.dmp Procdump attached, you can be more succesfull than me.
Created attachment 123459 [details] Backtrace of procdump Something is weird as it says: Unable to load image C:\Program Files (x86)\LibreOffice 5\program\mergedlo.dll, Win32 error 0n2 I do NOT have C:\Program Files (x86)\LibreOffice 5\ You have 32-bit LibreOffice?
Yes, LO 32 bits on Windows 64 bits at home and LO 32 bits on Windows 34 bits at work. I made the debug session at home.
I am able to repro on Win. Yet, I am not skilled enough in debugging to get a trace. Devs told me I would have to make the debugger catch the exception std::bad_alloc, but Windbg Event filters don't have anything resembling it. Maybe Visual Studio would help, but I've never used it to debug. Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: b89feb8018bf3610faf01e73995d576f6566e20b CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-03-07_03:36:17 Locale: fi-FI (fi_FI)
Reproducible on win7; Version: 4.5.0.0.alpha0+
I have Visual Studio Community and will give a try but, not before Wednesday. Not enough time.
So this sounds less like a regression and more like an out of memory situation. I'm not able to see anything strange during the opening of the doc except for a huge chart that might temporarily push the memory use above the 32bit threshold.
According to what's written and tested, I change the title to "FILEOPEN: ODS with large chart out of memory 'Bad Allocation' on 32-bit LO since LO 4.0". It worked before 4.0, so looks like a regression. Now, it works on 64-bit LO only. Tested in Windows. Opening in Linux with 32-bit LO was very slow, but it did open. 0:000> kb ChildEBP RetAddr Args to Child 00f1b098 77889c4e ffffffff 0000014d 00f1fe00 ntdll!ZwTerminateProcess+0x12 00f1b0b4 755979dc 00000000 77e8f3b0 ffffffff ntdll!RtlExitUserProcess+0x85 00f1b0c8 70453fac 0000014d 00f1b11c 7045427e kernel32!ExitProcessStub+0x12 00f1b0d4 7045427d 0000014d 9032f933 00f1fe00 MSVCR120!__crtExitProcess+0x15 [f:\dd\vctools\crt\crtw32\startup\crt0dat.c @ 774] 00f1b11c 7049bbc7 0000014d 00000001 00000000 MSVCR120!doexit+0x115 [f:\dd\vctools\crt\crtw32\startup\crt0dat.c @ 678] 00f1b130 6f74102b 0000014d 9036f64b 6fd3a890 MSVCR120!_exit+0xf [f:\dd\vctools\crt\crtw32\startup\crt0dat.c @ 433] 00f1b174 6f745835 00f1fc30 704397f2 00f1fe00 sofficeapp!desktop::`anonymous namespace'::FatalError+0x10b [c:\cygwin\home\tinderbox\master\desktop\source\app\app.cxx @ 447] 00f1fe0c 64b28c3c 90370140 00f1fe44 00000001 sofficeapp!desktop::Desktop::Main+0x1935 [c:\cygwin\home\tinderbox\master\desktop\source\app\app.cxx @ 1678] 00f1fe3c 64b290af 00000000 00f1febc 6f77d924 vcllo!ImplSVMain+0xbc [c:\cygwin\home\tinderbox\master\vcl\source\app\svmain.cxx @ 167] 00f1fe48 6f77d924 9036b983 6f7e674c 00000000 vcllo!SVMain+0x2f [c:\cygwin\home\tinderbox\master\vcl\source\app\svmain.cxx @ 205] *** ERROR: Symbol file could not be found. Defaulted to export symbols for S:\OFFICE\LO-OO-parallel\master\program\soffice.bin - 00f1febc 0030100a 90c95dc0 00f1fed4 0030103a sofficeapp!soffice_main+0x74 [c:\cygwin\home\tinderbox\master\desktop\source\app\sofficemain.cxx @ 135] WARNING: Stack unwind information not available. Following frames may be wrong. 00f1fec8 0030103a 004d8f18 00f1feec 00301078 soffice+0x100a 00f1fed4 00301078 00000002 004d8f18 00000002 soffice!main+0x1a 00f1feec 003012ce 00300000 00000000 00474166 soffice!main+0x58 00f1ff38 7559337a 7efde000 00f1ff84 77869882 soffice!main+0x2ae 00f1ff44 77869882 7efde000 76c7b5f6 00000000 kernel32!BaseThreadInitThunk+0xe 00f1ff84 77869855 0030119f 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70 00f1ff9c 00000000 0030119f 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b
(In reply to Timur from comment #20) > According to what's written and tested, I change the title to "FILEOPEN: ODS > with large chart out of memory 'Bad Allocation' on 32-bit LO since LO 4.0". > It worked before 4.0, so looks like a regression. Now, it works on 64-bit LO > only. Tested in Windows. > Opening in Linux with 32-bit LO was very slow, but it did open. > > > 0:000> kb > ChildEBP RetAddr Args to Child > 00f1b098 77889c4e ffffffff 0000014d 00f1fe00 ntdll!ZwTerminateProcess+0x12 > 00f1b0b4 755979dc 00000000 77e8f3b0 ffffffff ntdll!RtlExitUserProcess+0x85 > 00f1b0c8 70453fac 0000014d 00f1b11c 7045427e kernel32!ExitProcessStub+0x12 > 00f1b0d4 7045427d 0000014d 9032f933 00f1fe00 MSVCR120!__crtExitProcess+0x15 > [f:\dd\vctools\crt\crtw32\startup\crt0dat.c @ 774] > 00f1b11c 7049bbc7 0000014d 00000001 00000000 MSVCR120!doexit+0x115 > [f:\dd\vctools\crt\crtw32\startup\crt0dat.c @ 678] > 00f1b130 6f74102b 0000014d 9036f64b 6fd3a890 MSVCR120!_exit+0xf > [f:\dd\vctools\crt\crtw32\startup\crt0dat.c @ 433] > 00f1b174 6f745835 00f1fc30 704397f2 00f1fe00 sofficeapp!desktop::`anonymous > namespace'::FatalError+0x10b > [c:\cygwin\home\tinderbox\master\desktop\source\app\app.cxx @ 447] > 00f1fe0c 64b28c3c 90370140 00f1fe44 00000001 > sofficeapp!desktop::Desktop::Main+0x1935 > [c:\cygwin\home\tinderbox\master\desktop\source\app\app.cxx @ 1678] > 00f1fe3c 64b290af 00000000 00f1febc 6f77d924 vcllo!ImplSVMain+0xbc > [c:\cygwin\home\tinderbox\master\vcl\source\app\svmain.cxx @ 167] > 00f1fe48 6f77d924 9036b983 6f7e674c 00000000 vcllo!SVMain+0x2f > [c:\cygwin\home\tinderbox\master\vcl\source\app\svmain.cxx @ 205] > *** ERROR: Symbol file could not be found. Defaulted to export symbols for > S:\OFFICE\LO-OO-parallel\master\program\soffice.bin - > 00f1febc 0030100a 90c95dc0 00f1fed4 0030103a sofficeapp!soffice_main+0x74 > [c:\cygwin\home\tinderbox\master\desktop\source\app\sofficemain.cxx @ 135] > WARNING: Stack unwind information not available. Following frames may be > wrong. > 00f1fec8 0030103a 004d8f18 00f1feec 00301078 soffice+0x100a > 00f1fed4 00301078 00000002 004d8f18 00000002 soffice!main+0x1a > 00f1feec 003012ce 00300000 00000000 00474166 soffice!main+0x58 > 00f1ff38 7559337a 7efde000 00f1ff84 77869882 soffice!main+0x2ae > 00f1ff44 77869882 7efde000 76c7b5f6 00000000 kernel32!BaseThreadInitThunk+0xe > 00f1ff84 77869855 0030119f 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70 > 00f1ff9c 00000000 0030119f 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b That backtrace is completely useless. That is the place that actually catches the exception and not the one that throws the exception. The best way would be to start it in Visual Studio and break on thrown std::bad_alloc exceptions.
I will do a debug with MSVS like I said previously, but immediatly it’s not possible.
Created attachment 123906 [details] backtrace from Windbg.txt Sorry if not OK, but I read somewhere that ub may be useful. Please take a look.
Adding keyword 'preBisect' as this regression was introduced before branch 4.4 and therefore it can't be bibisected as there's no bibisect repository for this branch.
Created attachment 127725 [details] DrMemory logs.zip
Created attachment 133196 [details] WindDbg 32-bit StackTrace of bad assert On Windows 10 Pro 64-bit en-US with Version: 5.4.0.0.alpha1+ Build ID: c3e0b7dd4e7b1d33b8555e0acdf9f44cfc043ca2 CPU threads: 8; OS: Windows 6.19; UI render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2017-05-08_00:14:11 Locale: en-US (en_US); Calc: CL 32-bit WinDbg attached session aborts at http://opengrok.libreoffice.org/xref/core/package/source/xstor/ocompinstream.cxx#48 and #128 StackTrace attached... Same system with 64-bit build Version: 5.3.3.2 (x64) Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448 CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; Locale: en-US (en_US); Calc: group opens the SpreadSheet but see memory peak over 2.01MB, could be an issue on 32-bit systems.
No assert issue same Windows 10 Pro 64-bit en-US system with 64-bit master at about same build point: Version: 5.4.0.0.alpha1+ (x64) Build ID: 7a5eb2f9510e85a191a1b1948f38dafd22310677 CPU threads: 8; OS: Windows 6.19; UI render: GL; TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2017-05-08_22:44:31 Locale: en-US (en_US); Calc: group Memory peak usage shows 2.16 MB while manipulating.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Same with 6.0.4 and 6.1+ 32-bit: bad allocation.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9c3d8b1c64c2ce5a2fd39aa785df45f6b1d6628b Resolves: tdf#98558 oom under windows with certain charts It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
backport to 6-1 in gerrit
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b707def5e9696c429cfb1dbe8479d5b63046e800&h=libreoffice-6-1 Resolves: tdf#98558 oom under windows with certain charts It will be available in 6.1.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.