Problem description: Steps to reproduce: 1.create new spreadsheet 2.Select a group of rows and columns 2.go to Format->Autoformat... 3.Select "OK" This happens only when "Autofit width and height" is selected, probably because the rows and columns selected are empty. This needs to be trapped and handled or have the autofit option greyed and unchecked if the selected cells are empty. Current behavior: App will completely crash Expected behavior: rows autoformat as requested (even if cells are empty) Platform (if different from the browser): Windows 7 SP1 x32 Browser: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0
Can you please attach a test document and a detailed instruction how to reproduce it? I can't reproduce it here with a master build and memcheck does not show anything suspicious.
Created attachment 58647 [details] Blank ods spreadsheet NOTES: This seems to have something to do with a fresh document. I will add an additional step to the below <step 1a> that simply adds text to a cell and then deletes it, which would also result in a blank spreadsheet, but now everything works as desired. This seems to have something to do with a spreadsheet that hasn't had anything added to it yet; completely virgin, if you will. Perhaps the spreadsheet hasn't been completely loaded into memory, since nothing has been added to it yet, and that causes the autoformat to act on cells that don't yet exist? (thank you for letting me help out; I really love LibO!) To reproduce: A. Windows 7 x32 SP1 B. LibreOffice 3.5.1.2 Build ID: dc9775d-05ecbee-0851ad3-1586698-727bf66 C. Oracle Java 1.6.0_22-b04 1. Open the attached spreadsheet (it's just a blank spreadsheet I created by right clicking on Windows desktop and selecting new->OpenDocument Spreadsheet). <<1a. To make this NOT happen, type "blah" into cell A1 and then erase it. then proceed to step 2.>> 2. Select a box of cells with the mouse (I selected B3:E13). 3. Go to the FORMAT menu, select AUTOFORMAT... 4. When the dialog opens for AUTOFORMAT, select "more" on the lower right, and make sure that "Autofit width and height" is checked. (if it isn't the crash won't happen) 5. Select "OK" at the top right. 6. (App will crash and windows will close it) The windows application error log shows: (XML) - <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> - <System> <Provider Name="Windows Error Reporting" /> <EventID Qualifiers="0">1001</EventID> <Level>4</Level> <Task>0</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2012-03-18T22:40:57.000000000Z" /> <EventRecordID>2347</EventRecordID> <Channel>Application</Channel> <Computer>Daddy-PC</Computer> <Security /> </System> - <EventData> <Data>2829146127</Data> <Data>5</Data> <Data>BEX</Data> <Data>Not available</Data> <Data>0</Data> <Data>soffice.bin</Data> <Data>3.5.0.102</Data> <Data>4f55e306</Data> <Data>MSVCR90.dll</Data> <Data>9.0.30729.6161</Data> <Data>4dace5b9</Data> <Data>0006ccd5</Data> <Data>c0000417</Data> <Data>00000000</Data> <Data /> <Data>C:\Users\Vince\AppData\Local\Temp\WERD488.tmp.WERInternalMetadata.xml</Data> <Data>C:\Users\Vince\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_soffice.bin_469243e6dad01a50641dc376aed9df8acba1380_1ce9f0de</Data> <Data /> <Data>0</Data> <Data>688124e0-714b-11e1-b849-8fef8c934a78</Data> <Data>0</Data> </EventData> </Event>
Also, not sure if this is relevant, but LibreOffice is completely unloaded from memory and the spreadsheet we're looking at is the only one to load. :) The workaround for this problem seems to be to just type something into the spreadsheet anywhere, prior to attempting to autoformat. I think I found it because I format first and then enter data. It's a legacy from my Excel days. :P
Hello I confirm the crash, not just when selected cells are empty, but always when the "Autofit width and height" option is checked. Steps to Reproduce: 1. File > New > Spreadsheet (same with an existing one) 2. Select A1:D4 3. Format > AutoFormat 4. Close by OK Actual Results: The application crashed. Expected Results: Default AutoFormat applied to selection Steps to *not* reproduce: 1. File > New > Spreadsheet (same with an existing one) 2. Select A1:D4 3. Format > AutoFormat 4. Click More > Uncheck "Autofit width and height" 5. Close by OK Actual Results & Expected Results: Default AutoFormat applied to selection Build & Platform: LibreOffice 3.5.2.2 Version ID : 281b639-6baa1d3-ef66a77-d866f25-f36d45f Windows 7 64bits Regards Pierre-Yves
(In reply to comment #4) > Build & Platform: > LibreOffice 3.5.2.2 > Version ID : 281b639-6baa1d3-ef66a77-d866f25-f36d45f > Windows 7 64bits Additionnal information (fr-discuss) : Reproduced: Same platform (LibO 3.5.2.2 & Windows 7 64 bits) Not Reproduced : - LibO 3.5.2.2 & Windows XP SP3 - LibreOffice 3.5.1.2 & Archlinux 64 bits Regards Pierre-Yves
Not Reproduced : - LibreOffice 3.5.1.2 & Windows 7 SP1 32bits Regards, Bernard Ribot
Ok, I think I found it. Looks like memory corruption when adjusting row and column heights in the auto format code. I suspect that i need to create a local copy of ScMarkData to prevent changes that invalidate the iterators. I need to investigate that further.
*** Bug 48603 has been marked as a duplicate of this bug. ***
Created attachment 65387 [details] Bug 47466 - WinDbg session Confirmed with: LO 3.5.5.3 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Attached full WinDbg session with mini dump file loaded generated by procdump soffice.bin -h.
NEW as bug confirmed and bt attached.
Confirmed with: LO 3.6.0.4 Build ID: own W7 debug build Windows 7 Ultimate 64 bit Nombre del evento de problema: BEX Nombre de la aplicación: soffice.bin Versión de la aplicación: 3.6.0.104 Marca de tiempo de la aplicación: 5012ee18 Nombre del módulo con errores: MSVCR90.dll Versión del módulo con errores: 9.0.30729.6161 Marca de tiempo del módulo con errores: 4dace5b9 Desplazamiento de excepción: 0006ccd5 Código de excepción: c0000417 Datos de excepción: 00000000 Versión del sistema operativo: 6.1.7600.2.0.0.256.1 Id. de configuración regional: 2058 Información adicional 1: 8598 Información adicional 2: 85988d5bded9b77aa9463069f41704e3 Información adicional 3: ccd7 Información adicional 4: ccd75f3dae0810294ff141db9e994788
*** Bug 54272 has been marked as a duplicate of this bug. ***
WORKSFORME with Version 3.6.2.1 (Build ID: ba822cc) with Windows XP & Windows 7 64bits
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f843850ee9994653673ef5591aae875d7fb22fed fdo#47466 FORMATTING: Autoformat empty rows causes app to crash 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.
As indicated in http://nabble.documentfoundation.org/Wrong-indentation-which-leads-to-segfault-in-sc-source-ui-docshell-docfunc-cxx-td4026726.html, I reproduced this with master sources but not with 4.0 sources or 3.5 Debian packages. (I've still got to build 3.6 sources and test with it)
I reproduced the crash with 3.6 sources with same bt and console logs: /usr/include/c++/4.7/debug/safe_iterator.h:263:error: attempt to dereference a past-the-end iterator. Objects involved in the operation: iterator "this" @ 0x0x7fffcf7ae420 { type = N11__gnu_debug14_Safe_iteratorISt23_Rb_tree_const_iteratorIsENSt7__debug3setIsSt4lessIsESaIsEEEEE (mutable iterator); state = past-the-end; references sequence with type `NSt7__debug3setIsSt4lessIsESaIsEEE' @ 0x0x7fffcf7ae420 } #0 0x00007f13f9915475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007f13f99186f0 in *__GI_abort () at abort.c:92 #2 0x00007f13fa1ba31d in __gnu_debug::_Error_formatter::_M_error() const () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x00007f13dd919a4c in __gnu_debug::_Safe_iterator<std::_Rb_tree_const_iterator<short>, std::__debug::set<short, std::less<short>, std::allocator<short> > >::operator* ( this=0x7fffcf7ae420) at /usr/include/c++/4.7/debug/safe_iterator.h:261 #4 0x00007f13ddf17619 in ScDocFunc::AutoFormat (this=0x195cff0, rRange=..., pTabMark=0x1a34b60, nFormatNo=1, bRecord=true, bApi=false) at /home/julien/compile-libreoffice/libo_3_6/sc/source/ui/docshell/docfunc.cxx:3738 #5 0x00007f13de32121a in ScViewFunc::AutoFormat (this=0x1a33210, nFormatNo=1, bRecord=1 '\001') at /home/julien/compile-libreoffice/libo_3_6/sc/source/ui/view/viewfun2.cxx:1571 #6 0x00007f13de206eba in ScCellShell::Execute (this=0x1a529a0, rReq=...) at /home/julien/compile-libreoffice/libo_3_6/sc/source/ui/view/cellsh3.cxx:848 The patch of comment14 works too.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fbbbcdde585636aea0db1741a0a0ddcc7e0358f3&h=libreoffice-4-0 fdo#47466 FORMATTING: Autoformat empty rows causes app to crash It will be available in LibreOffice 4.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.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5fe2b0eee8058a64745a7a51fdd2ac5e102300ee&h=libreoffice-3-6 fdo#47466 FORMATTING: Autoformat empty rows causes app to crash It will be available in LibreOffice 3.6.5. 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.
Seems that bug had been fixed, no crash while reproducing. Tested with: LO 4.0.3.3 (Win7 Home Premium 32bit)