Created attachment 99645 [details] Repro file When opening a mutated DOCX file, an ASan build of LO 4.4.0.0 alpha0 will crash: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../include/c++/4.7/debug/safe_iterator.h:278: error: attempt to dereference a past-the-end iterator. Objects involved in the operation: iterator "this" @ 0x0x7ffffffe1850 { type = N11__gnu_debug14_Safe_iteratorISt23_Rb_tree_const_iteratorISt4pairIKN3rtl8OUStringEPN3oox9drawingml3dgm5PointEEENSt7__debug3mapIS4_SA_St4lessIS4_ESaISB_EEEEE (constant iterator); state = past-the-end; references sequence with type `NSt7__debug3mapIN3rtl8OUStringEPN3oox9drawingml3dgm5PointESt4lessIS2_ESaISt4pairIKS2_S7_EEEE' @ 0x0x7ffffffe1850 } Original OO file: SmartArt_O12_Word_TextWrapping.docx Mutated OO file (repro file): crash-30908.docx Modified XML file: word/diagrams/data6.xml Modifications: - in tag "dgm:pt", attribute "modelId" was switched from "{3F7ADC05-450D-4E79-A95B-8ED0E6BDF414}" to "%s%n%s%n%s%n%s%n%s%n" - in tag "dgm:prSet", attribute "phldrT" was switched from "[Text]" to "%s%n%s%n%s%n%s%n%s%n" - in tag "dgm:pt", attribute "cxnId" was switched from "{0FB7E5E5-D6BB-4789-AFA2-9E9DD009D957}" to "Abc123"
Created attachment 99647 [details] Original file
On pc Debian x86-64 with master sources updated yesterday, I could reproduce the crash but couldn't get a full bt, here's what I got: Program received signal SIGABRT, Aborted. 0x00002aaaab2883a9 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 0x00002aaaab2883a9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00002aaaab28b4c8 in __GI_abort () at abort.c:89 #2 0x00002aaaabcda745 in __gnu_debug::_Error_formatter::_M_error() const () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x00002aaadba145ea in __gnu_debug::_Safe_iterator<std::_Rb_tree_const_iterator<std::pair<rtl::OUString const, oox::drawingml::dgm::Point*> >, std::__debug::map<rtl::OUString, oox::drawingml::dgm::Point*, std::less<rtl::OUString>, std::allocator<std::pair<rtl::OUString const, oox::drawingml::dgm::Point*> > > >::operator-> (this=0x7ffffffebbc0) at /usr/include/c++/4.8/debug/safe_iterator.h:277 Python Exception <class 'RuntimeError'> maximum recursion depth exceeded: Fatal Python error: Cannot recover from stack overflow. Current thread 0x00002b9a8c32b600: File "/home/julien/compile-libreoffice/libreoffice/solenv/gdb/libreoffice/util/printing.py", line 104 in __call__ File "/home/julien/compile-libreoffice/libreoffice/solenv/gdb/boost/smart_ptr.py", line 40 in to_string repeat several times then, #4 0x00002aaadba10316 in oox::drawingml::LayoutNode::setupShape (this=0x90f5b40, rShape=Aborted (core dumped) /home/julien/compile-libreoffice/libreoffice/solenv/gbuild/Module.mk:161: recipe for target 'debugrun' failed make[1]: *** [debugrun] Error 134 Makefile:224: recipe for target 'build' failed make: *** [build] Error 2 (don't know if there's a link with: Starting program: /home/julien/compile-libreoffice/libreoffice/instdir/program/soffice.bin --writer warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaacb000 warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Traceback (most recent call last): File "/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20-gdb.py", line 59, in <module> from libstdcxx.v6.printers import register_libstdcxx_printers File "/usr/lib/x86_64-linux-gnu/../../share/gcc-4.9/python/libstdcxx/v6/printers.py", line 392 raise ValueError, "Unsupported implementation for %s" % str(node.type) ^ SyntaxError: invalid syntax ) Anyway, I finally found the problem was here: 401 while( aVecIter != aVecEnd ) 402 { 403 DiagramData::PointNameMap::const_iterator aDataNode2=rDgm.getData()->getPointNameMap().find(aVecIter->first); 404 if( aVecIter->second == 0 ) The result of find isn't checked against end iterator. Adding this prevents from the crash: if (aDataNode2 != rDgm.getData()->getPointNameMap().end()) But several possibilities: 1) just test if != end iterator and keep on the loop 2) if = end iterator and break the loop 3) if = end iterator, throw an exception 4) other?
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c84ce79132c674b4c2d31da8997ed77671323dfe Resolves: fdo#79129 Crash in oox::drawingml::LayoutNode::setupShape 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.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f5c7ce25cec1a01a1f154c180d46fc97b32a2105&h=libreoffice-4-2 Resolves: fdo#79129 Crash in oox::drawingml::LayoutNode::setupShape It will be available in LibreOffice 4.2.7. 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.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=97291b92b70249c1bcdca33425585b201a1822db&h=libreoffice-4-3 Resolves: fdo#79129 Crash in oox::drawingml::LayoutNode::setupShape It will be available in LibreOffice 4.3.3. 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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.