Bug Hunting Session
Bug 47466 - FORMATTING: Autoformat empty rows causes app to crash
Summary: FORMATTING: Autoformat empty rows causes app to crash
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.5.1 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA target:4.1.0 target:4.0.0.1 targe...
Keywords:
: 48603 54272 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-03-17 20:31 UTC by Vince Hannon
Modified: 2013-05-10 03:33 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Blank ods spreadsheet (6.40 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-03-18 16:13 UTC, Vince Hannon
Details
Bug 47466 - WinDbg session (9.12 KB, text/plain)
2012-08-10 12:43 UTC, bfoman (inactive)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vince Hannon 2012-03-17 20:31:15 UTC
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
Comment 1 Markus Mohrhard 2012-03-18 08:23:27 UTC
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.
Comment 2 Vince Hannon 2012-03-18 16:13:31 UTC
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>
Comment 3 Vince Hannon 2012-03-18 16:20:02 UTC
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
Comment 4 pierre-yves samyn 2012-04-08 08:58:22 UTC
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
Comment 5 pierre-yves samyn 2012-04-08 23:53:06 UTC
(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
Comment 6 ribotb 2012-04-09 03:18:35 UTC
Not Reproduced : 
- LibreOffice 3.5.1.2 & Windows 7 SP1 32bits

Regards,
Bernard Ribot
Comment 7 Markus Mohrhard 2012-04-09 08:17:00 UTC
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.
Comment 8 Markus Mohrhard 2012-04-12 07:10:47 UTC
*** Bug 48603 has been marked as a duplicate of this bug. ***
Comment 9 bfoman (inactive) 2012-08-10 12:43:38 UTC
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.
Comment 10 bfoman (inactive) 2012-08-10 12:44:09 UTC
NEW as bug confirmed and bt attached.
Comment 11 Valente 2012-08-20 23:15:05 UTC
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
Comment 12 bfoman (inactive) 2012-08-31 07:44:48 UTC
*** Bug 54272 has been marked as a duplicate of this bug. ***
Comment 13 pierre-yves samyn 2012-09-14 09:48:02 UTC
WORKSFORME with Version 3.6.2.1 (Build ID: ba822cc) with Windows XP & Windows 7 64bits
Comment 14 Not Assigned 2013-01-01 15:41:09 UTC
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.
Comment 15 Julien Nabet 2013-01-01 15:42:19 UTC
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)
Comment 16 Julien Nabet 2013-01-01 18:35:19 UTC
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.
Comment 17 Not Assigned 2013-01-02 15:46:55 UTC
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.
Comment 18 Not Assigned 2013-01-02 16:03:17 UTC
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.
Comment 19 ign_christian 2013-05-10 03:33:42 UTC
Seems that bug had been fixed, no crash while reproducing.

Tested with: LO 4.0.3.3 (Win7 Home Premium 32bit)