Bug 43304 - unoapi sc.ScDataPilotFieldsObj::com::sun::star::container::XNameAccess dereferences null ScDPObject::GetSource()
Summary: unoapi sc.ScDataPilotFieldsObj::com::sun::star::container::XNameAccess derefe...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Master old -3.6
Hardware: Other All
: medium normal
Assignee: Kohei Yoshida
URL:
Whiteboard: target:3.5
Keywords:
Depends on:
Blocks: Dev-subsequenttest-failures
  Show dependency treegraph
 
Reported: 2011-11-28 06:20 UTC by Stephan Bergmann
Modified: 2011-11-28 14:43 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Bergmann 2011-11-28 06:20:29 UTC
With sc/qa/unoapi enabled in subsequentcheck, it fails at

Creating: sc.ScDataPilotFieldsObj
LOG> Log started 28.10.2011 - 14:17:04
LOG> creating a Spreadsheet document
LOG> Creating a test environment
LOG> getting sheets
LOG> getting a sheet
LOG> Filing a table
LOG> Getting test object
LOG> Creating object - OK
Environment created
LOG> Log started 28.10.2011 - 14:17:04
checking: [sc.ScDataPilotFieldsObj::com::sun::star::container::XNameAccess] is iface: [com.sun.star.container.XNameAccess] testcode: [ifc.container._XNameAccess]
LOG> Execute: getByName()
LOG> reqiure getElementNames() ...
LOG> starting required method: getElementNames()
LOG> Execute: getElementNames()
LOG> getting elements names
com.sun.star.lang.DisposedException

at

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f5090eb2700 (LWP 32408)]
0x00007f50a50bf174 in lcl_GetFieldCount (rSource=..., rOrient=...) at /data/lo/core/sc/source/ui/unoobj/dapiuno.cxx:1586
1586	    Reference<XNameAccess> xDimsName(rSource->getDimensions());
(gdb) where
#0  0x00007f50a50bf174 in lcl_GetFieldCount (rSource=..., rOrient=...) at /data/lo/core/sc/source/ui/unoobj/dapiuno.cxx:1586
#1  0x00007f50a50c0666 in ScDataPilotFieldsObj::getElementNames (this=0x7f5092e0ee70) at /data/lo/core/sc/source/ui/unoobj/dapiuno.cxx:1797
#2  0x00007f50b8ec928d in callVirtualMethod (pThis=0x7f5092e0eec8, nVtableIndex=6, pRegisterReturn=0x7f50b0ce5e60, pReturnTypeRef=0x25f07a0, bSimpleReturn=false, pStack=0x7f5090eb12b0, nStack=0, pGPR=0x7f5090eb1360, nGPR=2, pFPR=0x7f5090eb1320, nFPR=0) at /data/lo/core/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:155
#3  0x00007f50b8ec9dcd in cpp_call (pThis=0x7f50b00ba7c0, aVtableSlot=..., pReturnTypeRef=0x25f07a0, nParams=0, pParams=0x0, pUnoReturn=0x7f50b0ce5e60, pUnoArgs=0x0, ppUnoExc=0x7f5090eb1708) at /data/lo/core/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:392
#4  0x00007f50b8eca8b2 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch (pUnoI=0x7f50b00ba7c0, pMemberDescr=0x25f7610, pReturn=0x7f50b0ce5e60, pArgs=0x0, ppException=0x7f5090eb1708) at /data/lo/core/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:586
#5  0x00007f50b5692440 in binaryurp::IncomingRequest::execute_throw (this=0x7f50980155a0, returnValue=0x7f5090eb1b60, outArguments=0x7f5090eb1ad0) at /data/lo/core/binaryurp/source/incomingrequest.cxx:263
#6  0x00007f50b56913bb in binaryurp::IncomingRequest::execute (this=0x7f50980155a0) at /data/lo/core/binaryurp/source/incomingrequest.cxx:89
#7  0x00007f50b56ac20e in binaryurp::(anonymous namespace)::request (pThreadSpecificData=0x7f50980155a0) at /data/lo/core/binaryurp/source/reader.cxx:107
#8  0x00007f50c8904859 in cppu_threadpool::JobQueue::enter (this=0x7f509801cf30, nDisposeId=<optimized out>, bReturnWhenNoJob=1 '\001') at /data/lo/core/cppu/source/threadpool/jobqueue.cxx:121
#9  0x00007f50c89056a5 in cppu_threadpool::ORequestThread::run (this=0x7f509800e0a0) at /data/lo/core/cppu/source/threadpool/thread.cxx:197
#10 0x00007f50c8906234 in cppu_requestThreadWorker (pVoid=0x7f509800e0a0) at /data/lo/core/cppu/source/threadpool/thread.cxx:47
#11 0x00007f50c982a60b in osl_thread_start_Impl (pData=0x7f5098013e10) at thread.c:277
#12 0x0000003980a07d90 in start_thread (arg=0x7f5090eb2700) at pthread_create.c:309
#13 0x00000039806eed8d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) print rSource
$1 = (const com::sun::star::uno::Reference<com::sun::star::sheet::XDimensionsSupplier> &) @0x7f5090eb1130: {<com::sun::star::uno::BaseReference> = {_pInterface = 0x0}, <No data fields>}

That looks related to <http://cgit.freedesktop.org/libreoffice/core/commit/?id=eafe57da830decb9ed3ac99af83de75489aa8c45> "Simple NULL pointer checks will prevent crashes...."
Comment 1 Kohei Yoshida 2011-11-28 07:22:24 UTC
Known issue - the same stack trace has been observed with one of the bug docs in Bug 43152.  I'll take a look at this.
Comment 2 Kohei Yoshida 2011-11-28 08:28:33 UTC
This document from Bug 42584

https://bugs.freedesktop.org/attachment.cgi?id=53319

produces the crash.
Comment 3 Kohei Yoshida 2011-11-28 09:40:22 UTC
I figured it out.  The source data range contains an empty field header, which, after Oracle integrated IBM's re-work of pivot table backend in 3.3, Calc started to reject as invalid source range.

IIRC, Oracle has since reverted that behavior to allow empty field headers, but we haven't.  That ultimately caused the import to fail for us.

I'll think about how to solve this meanwhile.
Comment 4 Kohei Yoshida 2011-11-28 09:46:24 UTC
(In reply to comment #3)
> I figured it out.  The source data range contains an empty field header, which,
> after Oracle integrated IBM's re-work of pivot table backend in 3.3, Calc
> started to reject as invalid source range.

Now, IIRC Excel has the same restriction, which is also one of the reasons why I decided to keep this behavior.  I don't believe Excel's behavior has changed wrt this after Excel 2007, but I believe the difference between Calc and Excel is that, Excel uses pivot cache data to re-build pivot table data during import, whereas we still don't support real pivot cache, and fetch data from the real sheet data.

Indeed, when you try to refresh the pivot table in Excel 2007, it refuses to refresh due to "invalid source range".

So, the absolute right way to fix this is to support real pivot cache.  But that will require a substantial rework (but is on my TODO list, has been for a long time).  For 3.5, I might just support empty column headers once again to get by this sort of stuff.
Comment 5 Eike Rathke 2011-11-28 11:19:13 UTC
(In reply to comment #4)
> For 3.5, I might just support empty column headers once again to
> get by this sort of stuff.

Yes please. I think ODF allows this even, doesn't it? Didn't look that
up. If so, we should be prepared anyway to encounter them.
Comment 6 Kohei Yoshida 2011-11-28 12:25:30 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > For 3.5, I might just support empty column headers once again to
> > get by this sort of stuff.
> 
> Yes please. I think ODF allows this even, doesn't it? Didn't look that
> up. If so, we should be prepared anyway to encounter them.

I didn't look it up either.  But I'm on it right now.
Comment 7 Kohei Yoshida 2011-11-28 14:43:58 UTC
Fixed on master, by allowing empty field labels in pivot tables.

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1dcb62fe485e8082068679c4167e263b1957d94d