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...."
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.
This document from Bug 42584 https://bugs.freedesktop.org/attachment.cgi?id=53319 produces the crash.
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.
(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.
(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.
(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.
Fixed on master, by allowing empty field labels in pivot tables. http://cgit.freedesktop.org/libreoffice/core/commit/?id=1dcb62fe485e8082068679c4167e263b1957d94d