Bug 80813 - FILEOPEN: Spreadsheet created in 3.6 crashes when opened in 4.2.5.2
Summary: FILEOPEN: Spreadsheet created in 3.6 crashes when opened in 4.2.5.2
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.5.2 release
Hardware: All All
: highest critical
Assignee: Not Assigned
URL:
Whiteboard: odf target:4.2.6
Keywords: haveBacktrace, regression
Depends on:
Blocks: mab4.2
  Show dependency treegraph
 
Reported: 2014-07-02 15:39 UTC by Mike
Modified: 2015-03-04 17:10 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Offending Workbook (86.07 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-07-03 20:20 UTC, Mike
Details
backtrace from linux (14.32 KB, text/plain)
2014-07-03 22:11 UTC, Yousuf Philips (jay) (retired)
Details
formatting corrected (83.71 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-07-05 09:37 UTC, Jens S
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike 2014-07-02 15:39:28 UTC
Spreadsheet appears to open and display properly, but immediately crashes.  System is unable to recover it.  Further, the crash scenario also occurs when formulae are copied from the old spreadsheet and pasted into the 4.2.5.2 version.  This is being experienced with the portable version of Calc.
Comment 1 Yousuf Philips (jay) (retired) 2014-07-02 18:58:40 UTC
Hello Mike,

Please send us a sample file that shows this behaviour, so we can test against it.
Comment 2 Mike 2014-07-03 20:20:39 UTC
Created attachment 102219 [details]
Offending Workbook

Here is the specific workbook referenced above.  I have successfully opened up other workbooks and Writer documents.  Note that this was originally developed under 3.(early) on Ubuntu Linux and used with, I believe 3.6 portable for Windows.
Comment 3 Yousuf Philips (jay) (retired) 2014-07-03 22:09:19 UTC
Hi Mike,

Thank you for sample file. I have confirmed that it crashes in Linux Mint in 4.1.6, 4.2.5, 4.2.6. It doesnt crash in 3.6.7, 4.0.6 or 4.3.0.
Comment 4 Yousuf Philips (jay) (retired) 2014-07-03 22:11:03 UTC
Created attachment 102225 [details]
backtrace from linux
Comment 5 Jens S 2014-07-05 09:37:39 UTC
Created attachment 102295 [details]
formatting corrected
Comment 6 Jens S 2014-07-05 09:38:33 UTC
I could open the file in OpenOffice 4.01 and I found errors in sheet1 and sheet2.
All cells with currencies was formatted as 'Standard' but showed correct as currency (RED for negative values and BLACK for positive with a $ in front)
Column F in sheet1 has an error in conditional formatting (second condition should be between 1000,1 and 2000 - not between 100,1 and 2000)

After correcting the errors I could open the file in LibreOffice 4.2.5
Comment 7 Michael Meeks 2014-07-05 20:49:22 UTC
Loads fine for me in master (4.4) and in libreoffice-4-3 (4.3.0rcs).
I can get it to crash in libreoffice 4.2.<n> immediately after load though.

A trace with symbols is:

#0  0xae0e6a50 in ScPatternAttr::GetItem (this=0x8bb01a0, nWhichP=129) at /data/opt/libreoffice/libreoffice-4-2/sc/inc/patattr.hxx:71
#1  0xae11a326 in ScColumn::GetNeededSize (this=0x8780298, nRow=37, pDev=0x880c450, nPPTX=0, nPPTY=0, rZoomX=1/1, rZoomY=1/1, bWidth=true, 
    rOptions=...) at /data/opt/libreoffice/libreoffice-4-2/sc/source/core/data/column2.cxx:145
#2  0xae1eea72 in ScTable::GetNeededSize (this=0x8780018, nCol=8, nRow=37, pDev=0x880c450, nPPTX=0, nPPTY=0, rZoomX=1/1, rZoomY=1/1, 
    bWidth=true, bTotalSize=true) at /data/opt/libreoffice/libreoffice-4-2/sc/source/core/data/table1.cxx:452
#3  0xae16b360 in ScDocument::GetNeededSize (this=0x8707394, nCol=8, nRow=37, nTab=0, pDev=0x880c450, nPPTX=0, nPPTY=0, rZoomX=1/1, rZoomY=1/1, 
    bWidth=true, bTotalSize=true) at /data/opt/libreoffice/libreoffice-4-2/sc/source/core/data/document.cxx:3937
#4  0xae165ff9 in ScDocument::IdleCalcTextWidth (this=0x8707394) at /data/opt/libreoffice/libreoffice-4-2/sc/source/core/data/documen8.cxx:644
#5  0xae389d79 in ScModule::IdleHandler (this=0x86f86c8) at /data/opt/libreoffice/libreoffice-4-2/sc/source/ui/app/scmod.cxx:1951
#6  0xb6b5b1f4 in Call (pCaller=0x86f8720, this=0x86f8730) at /data/opt/libreoffice/libreoffice-4-2/include/tools/link.hxx:123
#7  Timer::Timeout (this=0x86f8720) at /data/opt/libreoffice/libreoffice-4-2/vcl/source/app/timer.cxx:225
#8  0xb6b5b2a7 in Timer::ImplTimerCallbackProc () at /data/opt/libreoffice/libreoffice-4-2/vcl/source/app/timer.cxx:121
#9  0xb37dd3d0 in CallCallback (this=<optimized out>) at /data/opt/libreoffice/libreoffice-4-2/vcl/inc/saltimer.hxx:53
#10 sal_gtk_timeout_dispatch (pSource=pSource@entry=0x8dd8368) at /data/opt/libreoffice/libreoffice-4-2/vcl/unx/gtk/app/gtkdata.cxx:834
#11 0xb5ed97de in g_main_dispatch (context=0x84ca200, context@entry=0x8513b08) at gmain.c:3066
#12 g_main_context_dispatch (context=context@entry=0x84ca200) at gmain.c:3642
Comment 8 Michael Meeks 2014-07-05 21:10:58 UTC
Valgrind shows this guy ...

==30310== Invalid read of size 4
==30310==    at 0x10517A4D: ScPatternAttr::GetItem(unsigned short) const (patattr.hxx:71)
==30310==    by 0x1054B325: ScColumn::GetNeededSize(long, OutputDevice*, double, double, Fraction const&, Fraction const&, bool, ScNeededSizeOptions const&) const (column2.cxx:145)
==30310==    by 0x1061FA71: ScTable::GetNeededSize(short, long, OutputDevice*, double, double, Fraction const&, Fraction const&, bool, bool) (table1.cxx:452)
==30310==    by 0x1059C35F: ScDocument::GetNeededSize(short, long, short, OutputDevice*, double, double, Fraction const&, Fraction const&, bool, bool) (document.cxx:3937)
==30310==    by 0x10596FF8: ScDocument::IdleCalcTextWidth() (documen8.cxx:644)
==30310==    by 0x107BAD78: ScModule::IdleHandler(void*) (scmod.cxx:1951)
==30310==    by 0x51A21F3: Timer::Timeout() (link.hxx:123)
==30310==    by 0x51A22A6: Timer::ImplTimerCallbackProc() (timer.cxx:121)
==30310==    by 0x94723CF: sal_gtk_timeout_dispatch (saltimer.hxx:53)
...
==30310==  Address 0xfbe3ddc is 12 bytes inside a block of size 24 free'd
==30310==    at 0x402B6AD: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==30310==    by 0x49DDB53: SfxItemPool::Remove(SfxPoolItem const&) (itempool.cxx:886)
==30310==    by 0x1057DBE6: ScDocumentPool::Remove(SfxPoolItem const&) (docpool.cxx:637)
==30310==    by 0x10514060: ScAttrArray::SetPatternArea(long, long, ScPatternAttr const*, bool, ScEditDataArray*) (attarray.cxx:505)
==30310==    by 0x105141F4: ScAttrArray::SetPattern(long, ScPatternAttr const*, bool) (attarray.cxx:349)
==30310==    by 0x10523A7E: ScColumn::ApplyAttr(long, SfxPoolItem const&) (column.cxx:747)
==30310==    by 0x1054A62C: ScColumn::SetNumberFormat(long, unsigned long) (column2.cxx:2927)
==30310==    by 0x10625D29: ScTable::SetNumberFormat(short, long, unsigned long) (table2.cxx:1871)
==30310==    by 0x1059B4AB: ScDocument::SetNumberFormat(ScAddress const&, unsigned long) (document.cxx:3403)
==30310==    by 0x105FDE96: ScFormulaCell::InterpretTail(ScFormulaCell::ScInterpretTailParameter) (formulacell.cxx:1686)
==30310==    by 0x10600C40: ScFormulaCell::Interpret() (formulacell.cxx:1337)
==30310==    by 0x1060114E: ScFormulaCell::MaybeInterpret() (formulacell.cxx:2165)
==30310==    by 0x10601282: ScFormulaCell::IsValue() (formulacell.cxx:2196)
==30310==    by 0x10570059: lcl_GetCellContent(ScRefCellValue&, bool, double&, rtl::OUString&, ScDocument const*) (conditio.cxx:742)
==30310==    by 0x105735E0: ScConditionEntry::IsCellValid(ScRefCellValue&, ScAddress const&) const (conditio.cxx:1262)
==30310==    by 0x10573674: ScConditionalFormat::GetCellStyle(ScRefCellValue&, ScAddress const&) const (conditio.cxx:1906)
==30310==    by 0x1058BE41: ScDocument::GetCondResult(ScRefCellValue&, ScAddress const&, ScConditionalFormatList const&, std::vector<unsigned long, std::allocator<unsigned long> > const&) const (documen4.cxx:816)
==30310==    by 0x1058C1EC: ScDocument::GetCondResult(short, long, short) const (documen4.cxx:802)
==30310==    by 0x1054B054: ScColumn::GetNeededSize(long, OutputDevice*, double, double, Fraction const&, Fraction const&, bool, ScNeededSizeOptions const&) const (column2.cxx:134)
==30310==    by 0x1061FA71: ScTable::GetNeededSize(short, long, OutputDevice*, double, double, Fraction const&, Fraction const&, bool, bool) (table1.cxx:452)
==30310==    by 0x1059C35F: ScDocument::GetNeededSize(short, long, short, OutputDevice*, double, double, Fraction const&, Fraction const&, bool, bool) (document.cxx:3937)
==30310==    by 0x10596FF8: ScDocument::IdleCalcTextWidth() (documen8.cxx:644)
==30310==    by 0x107BAD78: ScModule::IdleHandler(void*) (scmod.cxx:1951)
==30310==    by 0x51A21F3: Timer::Timeout() (link.hxx:123)
==30310==    by 0x51A22A6: Timer::ImplTimerCallbackProc() (timer.cxx:121)
...

It seems that calling:

const SfxItemSet* pCondSet = pDocument->GetCondResult( nCol, nRow, nTab );

can delete the pPattern we are relying on - which is rather unfortunate.

Since the code is the same for 4.3 and 4.4 - it is somewhat unclear why this doesn't fail there too - presumably well worth investigating that =)

Ideally all these pointers would have fast intrusive references on them I suppose.
Comment 9 Michael Meeks 2014-07-05 21:17:02 UTC
Pushed a patch to gerrit, awaiting review from Kohei / Markus.
Comment 10 Commit Notification 2014-07-05 23:25:00 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=284c6681688f7075900d2351976c3611702411ce&h=libreoffice-4-2

fdo#80813 - avoid FMR by re-fetch pattern after a potential re-calculation.


It will be available in LibreOffice 4.2.6.

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 11 Joel Madero 2014-07-06 01:58:26 UTC
Removing bibisectrequest - doesn't seem necessary since there is a backtrace and Michael has already pushed a patch
Comment 12 Michael Meeks 2014-07-07 09:18:10 UTC
Still not completely happy about why this doesn't happen in 4.3 / master - the code looks ~the same there; perhaps we don't do load time calculation and its just hidden; but I loaded the same doc. in valgrind and did a shift-ctrl-F9 to force re-calc and ... nothing; so ...

Reluctantly closing for now; should be in the next 4.2.x ...