Created attachment 118064 [details] Crash loading this document This document with 'conditional formatting' cells crashes systematicly with LO Calc (versions 4.x.x). Conditional formatting contains over 3 conditions. Not recoverable with LO but is opened without erreor by Apache OpenOffice.org Additionnaly, recovery procedure MUST DISPLAY ALL STEPS and errors occurences. A MessageBox with "Unknown error" is without utility.
Created attachment 118065 [details] Example of console log for recovery procedures When recovery procedure and if it fails, displaying a simple MessageBox with "Unknown error" is WITHOUT UTILITY. I submit the following enhancement: Log console displaying all steps of the recovery procedure (reading sections, occurred errors with line number and description, ...) See the added file (console of GHTopo)
not reproduced on master (linux debian, 16 Gb, i7) did you try on LibreOffice 5 ? i notice external references and macros did you try to remove each and see if reproductible ? could you explicit what lets conclude conditionnal formatting is involved ? thanks a lot for reporting
Created attachment 118071 [details] backtrace WinDBG.txt Reproduced in Windows, with LO 4.0.5 up to 5.1+. Not reproduced in Linux Mint.
Wonder if it could be due to the fact that result of GetModuleFileNameW call isn't tested (see http://opengrok.libreoffice.org/xref/core/sal/osl/w32/module.cxx#399) Here are calls of GetModuleFileNameW (see http://opengrok.libreoffice.org/search?q=GetModuleFileNameW&project=core&defs=&refs=&path=&hist=). I don't know if we just keep on to the next one if it fails, or if an error message should popup, or something else.
With LO Debian package 4.4.5.2, I could open the file. With master sources updated yesterday (with enable-dbgutil), I can't even open the file because it consumes too much memory (more than 5,4GB whereas I've got 6GB with i5) Laurent: just for curiosity, did you notice something wrong with memory during your test?
I open it fine with : Linux-rpm_deb-x86_64@70-TDF-dbg, Branch:master, Time: 2015-08-19. Is bibisection possible here?
in response to Julien master, debian loading phase 5s calculating phase around 10 s saving around 4s regarding memory LibreOffice with that file loaded consumes 7.8 Gb stable after 10 consecutive savings
(In reply to Laurent Godard from comment #7) > ... > regarding memory > LibreOffice with that file loaded consumes 7.8 Gb > stable after 10 consecutive savings 7.8 Gb!! I understand better why I couldn't open the file :-) Eike: thought you might be interested in this one. BTW, if Kohei left and Markus almost left LO (he said he just wanted to finish his current tasks), are you the only expert now in Calc or do you know someone else? (I think about this, looking at https://wiki.documentfoundation.org/FindTheExpert)
I tried in 5.1.1 and loading the document consumes about additional ~800MB memory. Loading in master dbgutil build indeed consumes 5-6GB Apart from that, was the document designed to make things specifically slow? Almost every cell with content has a formula of a value and a STYLE() function. Why not apply a cell style instead and use a value instead of a formula? Also, the document contains more than 4500 conditional styles of which most are identical. For example there's a whole list of conditional styles applied to single cells on sheet 'RI - Juin 2014', which likely could be combined to a cell range instead. If done for all sheets, combining conditional formats to ranges and replacing formulas of value+STYLE() with value cells and assign the style, that would probably significantly reduce memory footprint. The Windows 32-bit version likely wasn't able to allocate the required memory hence gave up. I'm inclined to close this as worksforme. Future versions maybe could detect the conditional style repeats and combine them into ranges.
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.
This is an OOM problem and therefore the backtrace is not useful.
Created attachment 127660 [details] DrMemory logs I don't know if this can help. There was also DrMemory crash. ~Dr.M~~ Error #1: LEAK 112 direct bytes 0x02385050-0x023850c0 + 0 indirect bytes ~Dr.M~~ # 0 replace_RtlAllocateHeap [d:\drmemory_package\common\alloc_replace.c:3770] ~Dr.M~~ # 1 KERNELBASE.dll!LocalAlloc +0x5e (0x76d35a52 <KERNELBASE.dll+0x15a52>) ~Dr.M~~ # 2 SHELL32.dll!CommandLineToArgvW +0x89 (0x75839f4a <SHELL32.dll+0x19f4a>) ~Dr.M~~ # 3 soffice.exe!? +0x0 (0x00f71014 <soffice.exe+0x1014>) ~Dr.M~~ # 4 soffice.exe!? +0x0 (0x00f71258 <soffice.exe+0x1258>) ~Dr.M~~ # 5 soffice.exe!? +0x0 (0x00f71ba9 <soffice.exe+0x1ba9>) ~Dr.M~~ # 6 KERNEL32.dll!BaseThreadInitThunk +0x11 (0x7552338a <KERNEL32.dll+0x1338a>) ~Dr.M~~ ~Dr.M~~ Error #2: LEAK 112 direct bytes 0x02385228-0x02385298 + 0 indirect bytes ~Dr.M~~ # 0 replace_RtlAllocateHeap [d:\drmemory_package\common\alloc_replace.c:3770] ~Dr.M~~ # 1 KERNELBASE.dll!LocalAlloc +0x5e (0x76d35a52 <KERNELBASE.dll+0x15a52>) ~Dr.M~~ # 2 SHELL32.dll!CommandLineToArgvW +0x89 (0x75839f4a <SHELL32.dll+0x19f4a>) ~Dr.M~~ # 3 soffice.exe!? +0x0 (0x00f71014 <soffice.exe+0x1014>) ~Dr.M~~ # 4 soffice.exe!? +0x0 (0x00f714b8 <soffice.exe+0x14b8>) ~Dr.M~~ # 5 soffice.exe!? +0x0 (0x00f71ba9 <soffice.exe+0x1ba9>) ~Dr.M~~ # 6 KERNEL32.dll!BaseThreadInitThunk +0x11 (0x7552338a <KERNEL32.dll+0x1338a>) ~Dr.M~~ ~Dr.M~~ ERRORS FOUND: ~Dr.M~~ 0 unique, 0 total unaddressable access(es) ~Dr.M~~ 0 unique, 0 total uninitialized access(es) ~Dr.M~~ 0 unique, 0 total invalid heap argument(s) ~Dr.M~~ 0 unique, 0 total GDI usage error(s) ~Dr.M~~ 0 unique, 0 total handle leak(s) ~Dr.M~~ 0 unique, 0 total warning(s) ~Dr.M~~ 2 unique, 2 total, 224 byte(s) of leak(s) ~Dr.M~~ 0 unique, 0 total, 0 byte(s) of possible leak(s) ~Dr.M~~ ERRORS IGNORED: ~Dr.M~~ 1 unique, 1 total, 32 byte(s) of still-reachable allocation(s) ~Dr.M~~ (re-run with "-show_reachable" for details) ~Dr.M~~ Details: \DrMemory\drmemory\logs\DrMemory-soffice.exe.4940.000\results.txt ~Dr.M~~ WARNING: application exited with abnormal code 0xffffffff
Issue still reproducible in Version: 5.4.0.0.alpha0+ Build ID: eb7b03b052ffe8c2c577b2349987653db6c53f76 CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2017-02-26_22:34:18 Locale: en-GB (es_ES); Calc: group
Looks like fixed in 5.3 and 5.4+ so I'll close. Feel free to reopen if tested otherwise.
I do confirm it's not crashing in Version: 5.5.0.0.alpha0+ Build ID: fa89a464ca9c76332f533da0ab641da5acd00b52 CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@39, Branch:master, Time: 2017-05-19_01:24:56 Locale: es-ES (es_ES); Calc: group but it does in a build from 2017-05-15, nice!!