Download it now!
Bug 42584 - FILEOPEN: Parser errors and blank spreadsheet when opening XLS file
Summary: FILEOPEN: Parser errors and blank spreadsheet when opening XLS file
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.4.3 release
Hardware: x86-64 (AMD64) Linux (All)
: high critical
Assignee: Not Assigned
URL:
Whiteboard: BSA target:3.5 target:4.3.0
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-04 02:28 UTC by Pål Nilsen
Modified: 2014-03-07 21:57 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file that will produce parser errors (153.59 KB, application/vnd.ms-excel)
2011-11-04 02:28 UTC, Pål Nilsen
Details
XLSX file that crashes LibreOffice 3.4.3 (91.97 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2011-11-09 02:13 UTC, Pål Nilsen
Details
Parser errors (27.55 KB, text/plain)
2011-12-08 09:07 UTC, Pål Nilsen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pål Nilsen 2011-11-04 02:28:20 UTC
Created attachment 53142 [details]
Example file that will produce parser errors

Problem description:
The problem persists when opening Excel exports from the JIRA issue tracker. The files work fine on version 3.3.4 of LibreOffice.
When opening a file from Chrome or terminal the import dialog is not shown and the spreadsheet is blank.
I figured out that I can work around the problem by clicking the "File" menu and selecting the document under "Recent Documents". The import dialog will then show and after clicking OK, the spreadsheet shows data as expected.

Steps to reproduce:
1. Open an XLS file via the File, Open or from an external program or terminal
2. The scalc program starts and shows a blank spreadsheet
3. If you open via terminal you will see a large amount of parser errors

Current behavior:
Parser errors, no import dialog and blank spreadsheet

Expected behavior:
No errors, show the import dialog and data in the spreadsheet after clicking OK on the import.

Platform (if different from the browser):
Confirmed on LibreOffice 3.4.3 on both Ubuntu 11.04 and 11.10 x86_64. 
              
Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.106 Safari/535.2
Comment 1 Pål Nilsen 2011-11-09 02:13:01 UTC
Created attachment 53319 [details]
XLSX file that crashes LibreOffice 3.4.3

Attached an XLSX file that causes Calc to just close without any output.
Comment 2 Pål Nilsen 2011-11-09 02:14:52 UTC
(In reply to comment #1)
> Created attachment 53319 [details]
> XLSX file that crashes LibreOffice 3.4.3
> 
> Attached an XLSX file that causes Calc to just close without any output.

This file works fine on 3.3.4 by the way.
Comment 3 Petr Mladek 2011-11-21 10:21:42 UTC
I have reproduced the problem with LO-3.4.3. I do not see it with 3.4.4 and master build => it looks fixed

Feel free to reopen it, if you see the problem with 3.4.4 or later release.
Comment 4 Kohei Yoshida 2011-11-22 09:55:09 UTC
(In reply to comment #1)
> Created attachment 53319 [details]
> XLSX file that crashes LibreOffice 3.4.3
> 
> Attached an XLSX file that causes Calc to just close without any output.

Hello,

Could you open a new bug report for this XLSX file crashing Calc?  We need to keep each bug separate or else risk overlooking it.  Thanks a lot... Much appreciated.
Comment 5 Pål Nilsen 2011-12-02 07:08:18 UTC
Issue still occurs in LO 3.4.4 from Ubuntu repositories.
Comment 6 Petr Mladek 2011-12-08 05:57:33 UTC
Interesting, it works with LO-3.4.4 package from openSUSE. It does not work with the official LO-3.4.4 from FDO.

I wonder if it is related to a system library that is used to parse the file format.

Kohei, it is strange file format. How much do we support it?
Comment 7 Petr Mladek 2011-12-08 06:01:24 UTC
Also added Bjorn because it happens with Ubuntu packages but not with the openSUSE packages.

I slightly reduce the severity. The bug is there longer time. The file format rarely used. I think that it can't block the release.
Comment 8 Björn Michaelsen 2011-12-08 08:19:07 UTC
confirmed on 3.4.4-0ubuntu1
@rene: Do you see this too on debian?
Comment 9 Kohei Yoshida 2011-12-08 08:36:00 UTC
(In reply to comment #6)
> Interesting, it works with LO-3.4.4 package from openSUSE. It does not work
> with the official LO-3.4.4 from FDO.
> 
> I wonder if it is related to a system library that is used to parse the file
> format.
> 
> Kohei, it is strange file format. How much do we support it?

It's not a strange file format; it's an Excel-generated HTML file, disguised as an xls file, by having an .xls extension.  Well, sounds strange perhaps when you see it written, but I've seen a plenty of files like this it's not weird to me any more.

Since the reporter says sometimes the file opens, I would suspect it's the file format detection code failing to detect the correct filter type, and perhaps we are parsing the file using the wrong import filter.  Just a wild guess.

Also, as I've observed in the past, our file format detection code involves a little bit of "random luck", where different candidate format types are tested, and the first one gets selected.  The thing is, we store these format types in boost::unordered_map, and this container tends to order things differently depending on the version of boost used to build it.

That might explain different behaviors in different distro versions of even the same version.

But all of this is just a speculation.  Someone needs to debug our format detection code and see what really takes place there.
Comment 10 Kohei Yoshida 2011-12-08 08:38:18 UTC
Having said that, I thought I already fixed that randomness, though I'm not sure if that went into the 3.4.x version.

@Pål Nilsen
> Current behavior:
> Parser errors, no import dialog and blank spreadsheet

Could you attach the parser errors that you get when running from the terminal?  That might confirm or invalidate my speculation that the wrong import filter is used to parse the file.  Thanks a lot.
Comment 11 Björn Michaelsen 2011-12-08 08:40:50 UTC
#0  0x00007fffcee6cbb9 in lcl_GetFieldDataByIndex (rSource=<optimized out>, rOrient=..., nIndex=0, rFieldId=...)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sc/source/ui/unoobj/dapiuno.cxx:1634
#1  0x00007fffcee6ddb7 in ScDataPilotFieldsObj::GetObjectByIndex_Impl (this=0x2771810, nIndex=0)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sc/source/ui/unoobj/dapiuno.cxx:1733
#2  0x00007fffcee6deac in ScDataPilotFieldsObj::getByIndex (this=0x2771810, nIndex=0)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sc/source/ui/unoobj/dapiuno.cxx:1773
#3  0x00007fffd16eba43 in oox::xls::PivotTableField::finalizeImport (this=0x1f38700, rxDPDesc=<optimized out>)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/oox/source/xls/pivottablebuffer.cxx:529
#4  0x00007fffd16edca0 in operator() (a1=..., this=<synthetic pointer>, t=<optimized out>) at /usr/include/boost/bind/mem_fn_template.hpp:186
#5  operator()<boost::_mfi::mf1<void, oox::xls::PivotTableField, const com::sun::star::uno::Reference<com::sun::star::sheet::XDataPilotDescriptor>&>, boost::_bi::list1<oox::xls::PivotTableField&> >
    (a=<synthetic pointer>, f=<synthetic pointer>, this=<synthetic pointer>) at /usr/include/boost/bind/bind.hpp:313
#6  operator()<oox::xls::PivotTableField> (a1=<optimized out>, this=<synthetic pointer>) at /usr/include/boost/bind/bind_template.hpp:32
#7  operator() (rxValue=<optimized out>, this=<synthetic pointer>) at ../../inc/oox/helper/refvector.hxx:170
#8  for_each<__gnu_cxx::__normal_iterator<boost::shared_ptr<oox::xls::PivotTableField> const*, std::vector<boost::shared_ptr<oox::xls::PivotTableField>, std::allocator<boost::shared_ptr<oox::xls::PivotTableField> > > >, oox::RefVector<oox::xls::PivotTableField>::ForEachFunctor<boost::_bi::bind_t<void, boost::_mfi::mf1<void, oox::xls::PivotTableField, com::sun::star::uno::Reference<com::sun::star::sheet::XDataPilotDescriptor> const&>, boost::_bi::list2<boost::arg<1>, boost::reference_wrapper<com::sun::star::uno::Reference<com::sun::star::sheet::XDataPilotDescriptor> const> > > > > (
    __f=..., __last=<optimized out>, __first=<optimized out>) at /usr/include/c++/4.6/bits/stl_algo.h:4302
#9  forEach<boost::_bi::bind_t<void, boost::_mfi::mf1<void, oox::xls::PivotTableField, com::sun::star::uno::Reference<com::sun::star::sheet::XDataPilotDescriptor> const&>, boost::_bi::list2<boost::arg<1>, boost::reference_wrapper<com::sun::star::uno::Reference<com::sun::star::sheet::XDataPilotDescriptor> const> > > > (aFunctor=<optimized out>, this=0x205a020)
    at ../../inc/oox/helper/refvector.hxx:80
#10 forEachMem<void (oox::xls::PivotTableField::*)(com::sun::star::uno::Reference<com::sun::star::sheet::XDataPilotDescriptor> const&), boost::reference_wrapper<com::sun::star::uno::Reference<com::sun::star::sheet::XDataPilotDescriptor> const> > (aParam=..., pFunc=
    (void (oox::xls::PivotTableField::*)(oox::xls::PivotTableField * const, const com::sun::star::uno::Reference<com::sun::star::sheet::XDataPilotDescriptor> &)) 0x7fffd16eb9b0 <oox::xls::PivotTableField::finalizeImport(com::sun::star::uno::Reference<com::sun::star::sheet::XDataPilotDescriptor> const&)>, this=0x205a020) at ../../inc/oox/helper/refvector.hxx:96
#11 oox::xls::PivotTable::finalizeImport (this=0x205a010) at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/oox/source/xls/pivottablebuffer.cxx:1394
#12 0x00007fffd16ea6b5 in operator() (this=<synthetic pointer>, t=<optimized out>) at /usr/include/boost/bind/mem_fn_template.hpp:70
#13 operator()<boost::_mfi::mf0<void, oox::xls::PivotTable>, boost::_bi::list1<oox::xls::PivotTable&> > (a=<synthetic pointer>, f=<synthetic pointer>, this=<optimized out>)
    at /usr/include/boost/bind/bind.hpp:253
#14 operator()<oox::xls::PivotTable> (a1=<optimized out>, this=<synthetic pointer>) at /usr/include/boost/bind/bind_template.hpp:32
#15 operator() (rxValue=<optimized out>, this=<synthetic pointer>) at ../../inc/oox/helper/refvector.hxx:170
#16 for_each<__gnu_cxx::__normal_iterator<boost::shared_ptr<oox::xls::PivotTable> const*, std::vector<boost::shared_ptr<oox::xls::PivotTable>, std::allocator<boost::shared_ptr<oox::xls::PivotTable> > > >, oox::RefVector<oox::xls::PivotTable>::ForEachFunctor<boost::_bi::bind_t<void, boost::_mfi::mf0<void, oox::xls::PivotTable>, boost::_bi::list1<boost::arg<1> > > > > (__f=..., 
    __last=<optimized out>, __first=<optimized out>) at /usr/include/c++/4.6/bits/stl_algo.h:4302
#17 forEach<boost::_bi::bind_t<void, boost::_mfi::mf0<void, oox::xls::PivotTable>, boost::_bi::list1<boost::arg<1> > > > (this=<optimized out>, aFunctor=<optimized out>)
    at ../../inc/oox/helper/refvector.hxx:80
#18 forEachMem<void (oox::xls::PivotTable::*)()> (pFunc=(void (oox::xls::PivotTable::*)(oox::xls::PivotTable * const)) 0x7fffd16ed7b0 <oox::xls::PivotTable::finalizeImport()>, this=<optimized out>)
    at ../../inc/oox/helper/refvector.hxx:88
#19 oox::xls::PivotTableBuffer::finalizeImport (this=<optimized out>) at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/oox/source/xls/pivottablebuffer.cxx:1562
#20 0x00007fffd1730258 in oox::xls::WorkbookHelper::finalizeWorkbookImport (this=0x1cf34e0)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/oox/source/xls/workbookhelper.cxx:667
#21 0x00007fffd172a0ae in oox::xls::WorkbookFragment::finalizeImport (this=0x1cf3470)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/oox/source/xls/workbookfragment.cxx:297
#22 0x00007fffcf44f623 in sax_fastparser::FastSaxParser::parseStream (this=0x1bda3b0, maStructSource=<optimized out>)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sax/source/fastparser/fastparser.cxx:479
#23 0x00007fffd162061c in oox::core::FastParser::parseStream (this=0x1ba62d0, rInputSource=<optimized out>, bCloseStream=false)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/oox/source/core/fastparser.cxx:117
#24 0x00007fffd162072d in oox::core::FastParser::parseStream (this=0x1ba62d0, rxInStream=<optimized out>, rStreamName=..., bCloseStream=false)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/oox/source/core/fastparser.cxx:125
#25 0x00007fffd163013d in oox::core::XmlFilterBase::importFragment (this=0x1bda110, rxHandler=...)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/oox/source/core/xmlfilterbase.cxx:260
#26 0x00007fffd16acbef in oox::xls::ExcelFilter::importDocument (this=0x1bda110) at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/oox/source/xls/excelfilter.cxx:130
#27 0x00007fffd16247fd in oox::core::FilterBase::filter (this=0x1bda110, rMediaDescSeq=<optimized out>)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/oox/source/core/filterbase.cxx:523
#28 0x00007fffd16aced6 in oox::xls::ExcelFilter::filter (this=0x1bda110, rDescriptor=...)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/oox/source/xls/excelfilter.cxx:171
#29 0x00007ffff598b985 in SfxObjectShell::ImportFrom (this=<optimized out>, rMedium=...)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sfx2/source/doc/objstor.cxx:2603
#30 0x00007ffff5984576 in SfxObjectShell::DoLoad (this=0x1b60190, pMed=<optimized out>) at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sfx2/source/doc/objstor.cxx:894
#31 0x00007ffff59bdf19 in SfxBaseModel::load (this=0x1b64300, seqArguments=<optimized out>)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sfx2/source/doc/sfxbasemodel.cxx:1877
#32 0x00007ffff5a0290b in SfxFrameLoader_Impl::load (this=0x192ba90, rArgs=<optimized out>, _rTargetFrame=...)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sfx2/source/view/frmload.cxx:613
#33 0x00007fffdd3ec9d2 in framework::LoadEnv::impl_loadContent (this=0x192d968)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/framework/source/loadenv/loadenv.cxx:1152
#34 0x00007fffdd3eee28 in framework::LoadEnv::startLoading (this=0x192d968) at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/framework/source/loadenv/loadenv.cxx:412
#35 0x00007fffdd3819bb in framework::LoadDispatcher::impl_dispatch (this=0x192d8d0, rURL=..., lArguments=..., xListener=...)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/framework/source/dispatch/loaddispatcher.cxx:170
#36 0x00007fffdd381f58 in framework::LoadDispatcher::dispatchWithReturnValue (this=<optimized out>, rURL=<optimized out>, lArguments=<optimized out>)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/framework/source/dispatch/loaddispatcher.cxx:107
#37 0x00007ffff672401e in comphelper::SynchronousDispatch::dispatch (xStartPoint=<optimized out>, sURL=<optimized out>, sTarget=..., nFlags=<optimized out>, lArguments=...)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/comphelper/source/misc/synchronousdispatch.cxx:86
#38 0x00007ffff57d7ef0 in SfxApplication::OpenDocExec_Impl (this=<optimized out>, rReq=...)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sfx2/source/appl/appopen.cxx:1228
#39 0x00007ffff5859c00 in CallExec (rReq=..., pFunc=<optimized out>, this=0x128dce0) at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sfx2/inc/sfx2/shell.hxx:203
#40 SfxDispatcher::Call_Impl (this=0x12a2360, rShell=..., rSlot=..., rReq=..., bRecord=0 '\000')
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sfx2/source/control/dispatch.cxx:279
#41 0x00007ffff585cc4b in SfxDispatcher::Execute (this=0x12a2360, nSlot=5501, eCall=1, nModi=0, rArgs=...)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sfx2/source/control/dispatch.cxx:1363
#42 0x00007ffff57d8faa in SfxApplication::OpenDocExec_Impl (this=0x128dce0, rReq=...) at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sfx2/source/appl/appopen.cxx:818
#43 0x00007ffff5859c00 in CallExec (rReq=..., pFunc=<optimized out>, this=0x128dce0) at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sfx2/inc/sfx2/shell.hxx:203
#44 SfxDispatcher::Call_Impl (this=0x12a2360, rShell=..., rSlot=..., rReq=..., bRecord=1 '\001')
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sfx2/source/control/dispatch.cxx:279
#45 0x00007ffff585c3e4 in SfxDispatcher::PostMsgHandler (this=0x12a2360, pReq=0x1615e80)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sfx2/source/control/dispatch.cxx:1511
#46 0x00007ffff59ea98a in DoEvent_Impl (pPostedHint=<optimized out>, this=0x12a6640) at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sfx2/source/notify/hintpost.cxx:78
#47 SfxHintPoster::LinkStubDoEvent_Impl (pThis=<optimized out>, pCaller=<optimized out>)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/sfx2/source/notify/hintpost.cxx:82
#48 0x00007ffff3a73338 in Call (pCaller=<optimized out>, this=<optimized out>)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/solver/340/unxlngx6.pro/inc/tools/link.hxx:140
#49 ImplHandleUserEvent (pSVEvent=0x1612050) at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/vcl/source/window/winproc.cxx:1993
#50 ImplWindowFrameProc (pWindow=<optimized out>, nEvent=<optimized out>, pEvent=0x1612050)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/vcl/source/window/winproc.cxx:2565
#51 0x00007fffea38ce6a in CallCallback (pEvent=0x1612050, nEvent=22, this=0x12b4e30) at ../../../inc/vcl/salframe.hxx:294
#52 SalDisplay::DispatchInternalEvent (this=0x760e40) at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/vcl/unx/source/app/saldisp.cxx:2336
#53 0x00007fffebed1390 in GtkXLib::userEventFn (data=0x6dada0) at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/vcl/unx/gtk/app/gtkdata.cxx:816
#54 0x00007fffea60fa5d in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#55 0x00007fffea610258 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#56 0x00007fffea610429 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#57 0x00007fffebececc9 in GtkXLib::Yield (this=0x6dada0, bWait=true, bHandleAllCurrentEvents=<optimized out>)
    at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/vcl/unx/gtk/app/gtkdata.cxx:868
#58 0x00007ffff3886391 in ImplYield (i_bAllEvents=<optimized out>, i_bWait=true) at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/vcl/source/app/svapp.cxx:458
#59 Application::Yield (i_bAllEvents=false) at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/vcl/source/app/svapp.cxx:492
#60 0x00007ffff3886447 in Application::Execute () at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/vcl/source/app/svapp.cxx:435
#61 0x00007ffff792d7b1 in desktop::Desktop::Main (this=0x7fffffffe100) at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/desktop/source/app/app.cxx:1915
#62 0x00007ffff388d3a1 in ImplSVMain () at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/vcl/source/app/svmain.cxx:174
#63 0x00007ffff388d445 in SVMain () at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/vcl/source/app/svmain.cxx:211
#64 0x00007ffff7954225 in soffice_main () at /build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/desktop/source/app/sofficemain.cxx:67
#65 0x0000000000400ddb in sal_main () at main.c:36
#66 main (argc=<optimized out>, argv=<optimized out>) at main.c:35
Comment 12 Kohei Yoshida 2011-12-08 08:48:53 UTC
(In reply to comment #11)
> #0  0x00007fffcee6cbb9 in lcl_GetFieldDataByIndex (rSource=<optimized out>,
> rOrient=..., nIndex=0, rFieldId=...)

Just for completeness, this stacktrace is for the 2nd xlsx document, which we are not dealing with in this bug report.  (This btw is already fixed in 3.5.)

I still want to see the parser error output for the 1st Excel-generated HTML document.
Comment 13 Pål Nilsen 2011-12-08 09:07:49 UTC
Created attachment 54244 [details]
Parser errors

Attached parser errors from opening the document via the terminal.
Comment 14 Kohei Yoshida 2011-12-08 09:16:27 UTC
(In reply to comment #13)
> Created attachment 54244 [details]
> Parser errors
> 
> Attached parser errors from opening the document via the terminal.

Thanks.  This type of

Entity: line xx: parser error: ....

error message indeed comes from an external XML parser, which indicates that the file is incorrectly parsed as an XML file.

I've seen a similar problem before, and did fix it in 3.5.  The problem was that the Excel 2003 XML file detection code was way too simple, and incorrectly identified this type of HTML file as an Excel 2003 XML file, and proceeded with importing it using that filter instead of using the HTML import filter.

So, I would say please try again using 3.5, and if it's still there, please reopen this.
Comment 15 Commit Notification 2014-03-07 21:57:11 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=60b36a7968782f44fa9351649f8cdd28ad85f40d

fix OOXML validation error, related fdo#42584



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.