Created attachment 109942 [details] dotx bug LibreOffice ver: 4.3.4.1 i have some problems when i need open a .dotx file. First i open libreoffice with terminal for debug any problems and try to open a file (dotx), immediately the program is closed, never show any problem in terminal and the file never is loaded. A friend of the community libreoffice Venezuela says that these files are not a problem in the stable release and that i should download and install the newest version at day (at that time I had the version 4.3.2.2 ). Well after downloaded and install i'm here reporting the problem i hope find some solutions quickly thanks and greetings from Venezuela i have some screenshots powered by dropbox : https://www.dropbox.com/sh/3lnrphzg90nuudw/AAA6Yl_FtVmM_Q4p1hXCcjM-a?dl=0
Hello , Thank you for filing the bug. Please send us a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO', so please do change it back to 'UNCONFIRMED' once you have attached a document. (Please note that the attachment will be public, remove any sensitive information before attaching it.) How can I eliminate confidential data from a sample document? https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F Thank you
Thanks for respond immediately, here i will send the file for my is not necessary to Sanitize the File Before Submission, because is only for educational purpose on the university (computer engineering). Donwload powered by #dropbox: https://www.dropbox.com/s/w8znhgsq1001443/Plantilla%20Informe%20Final.dotx?dl=0
Created attachment 109995 [details] test file no crash with win7, LO 4.3.4
On pc Debian x86-64 with 4.3.3 LO Debian package, I could reproduce this. However, I don't reproduce this with master sources updated today.
Some element: /usr/include/c++/4.9/bits/stl_stack.h:164:error: attempt to access an element in an empty container. Objects involved in the operation: sequence "this" @ 0x0x2f50280 { type = St5stackIN12writerfilter7dmapper17TextAppendContextENSt7__debug5dequeIS2_SaIS2_EEEE; } Program received signal SIGABRT, Aborted. 0x00002aaaab28d107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce type. (gdb) bt #0 0x00002aaaab28d107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00002aaaab28e4e8 in __GI_abort () at abort.c:89 #2 0x00002aaaabcde655 in __gnu_debug::_Error_formatter::_M_error() const () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x00002aaad623bd9c in std::stack<writerfilter::dmapper::TextAppendContext, std::__debug::deque<writerfilter::dmapper::TextAppendContext, std::allocator<writerfilter::dmapper::TextAppendContext> > >::top (this=0x2f50280) at /usr/include/c++/4.9/bits/stl_stack.h:164 #4 0x00002aaad622f0ec in writerfilter::dmapper::DomainMapper_Impl::CloseFieldCommand (this=0x2f50230) at /home/julien/compile-libreoffice/libo_4_3/writerfilter/source/dmapper/DomainMapper_Impl.cxx:3941 #5 0x00002aaad61dab92 in writerfilter::dmapper::DomainMapper::lcl_text (this=0x2f4d060, data_=0x2aaad657abe4 <cFieldSep> "\024\025", len=1) at /home/julien/compile-libreoffice/libo_4_3/writerfilter/source/dmapper/DomainMapper.cxx:2702 #6 0x00002aaad6348219 in writerfilter::LoggedStream::text (this=0x2f4d078, data=0x2aaad657abe4 <cFieldSep> "\024\025", len=1) at /home/julien/compile-libreoffice/libo_4_3/writerfilter/source/resourcemodel/LoggedResources.cxx:175 #7 0x00002aaad62fa5a3 in writerfilter::ooxml::OOXMLFastContextHandler::fieldSeparator (this=0x3036f40) at /home/julien/compile-libreoffice/libo_4_3/writerfilter/source/ooxml/OOXMLFastContextHandler.cxx:774 #8 0x00002aaad6400e41 in writerfilter::ooxml::OOXMLFactory_wml::startAction (this=0x2f980d0, pHandler=0x3036f40) at /home/julien/compile-libreoffice/libo_4_3/workdir/CustomTarget/writerfilter/source/OOXMLFactory_wml.cxx:4962 #9 0x00002aaad62ed477 in writerfilter::ooxml::OOXMLFactory::startAction (this=0x2b74f00, pHandler=0x3036f40) at /home/julien/compile-libreoffice/libo_4_3/writerfilter/source/ooxml/OOXMLFactory.cxx:323
I should build from scratch my local 4.3 repo because it really seems a dup of fdo#79130
Ok I rebuilt and had the crash. #4 0x00002aaad510161e in writerfilter::dmapper::DomainMapper_Impl::CloseFieldCommand (this=0x2f8e8d0) at /home/julien/compile-libreoffice/libo_4_3/writerfilter/source/dmapper/DomainMapper_Impl.cxx:3947
Miklos: http://cgit.freedesktop.org/libreoffice/core/commit/?id=5a5d55a8a0f82406a8001015a723596f21d3562c should fix this one but m_bParaHadField is missing. Any idea how to fix the bug on 4.3 branch without cherry-picking several commits?
https://gerrit.libreoffice.org/#/c/13374/ to make it not crash for 4-3
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dcc914ab55feb844d5d71e6568801fa1ffd47f6c&h=libreoffice-4-3 Resolves: fdo#86662 don't crash on docx load It will be available in 4.3.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=85e973d3b95e66b7d396d94bf44011b5e8d51b21&h=libreoffice-4-3-5 Resolves: fdo#86662 don't crash on docx load It will be available in 4.3.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.