Created attachment 72166 [details] bt + console logs on master Problem description: On pc Debian x86-64 with master sources updated yesterday (commit ed338bc212725f422f0def21aafc82f05e350646) and a brand new LO profile, I had a crash trying to open the attachment of fdo#58277 Steps to reproduce: 1. Open Writer 2. Retrieve https://bugs.freedesktop.org/attachment.cgi?id=71628 3. Try open the file just retrieved Current behavior: Crash Expected behavior: No crash I don't reproduce this with 3.6 sources or 4.0 branch both updated yesterday. Operating System: Debian Version: 4.1.0.0.alpha0+ Master Last worked in: 4.0.0.0.beta2
Increase importance since it's a crash + regression
Can't reproduce using LO 4.1.0.0.alpha0+ (Build ID: de9475756effa8102cc4090db8d03393a02fdc6) TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2012-12-25_01:01:53 Mac OSX 10.8.2
Still can't reproduce using LO 4.1.0.0.alpha0+ (Build ID: 699132c269a6c6d9e815fc582e2e6a106e46923) TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2012-12-27_01:05:51 So, Linux only for the moment.
not reproducible on Windows Vista 64bit using Version 4.0.0.0.beta2+ (Build ID: 350ae8294a8df78403fd8cdce56b9aeb8178e13)
Debian GNU/linux 64, Libo 4.0beta2, can't reproduce, file opens just fine, I can scroll it, the close it without problems.
Terrence: could you give a try to this bug? Perhaps it's like fdo#55974, it can be reproduced only with specific configuration. Meanwhile, I've made some cleanup on my laptop. There were several gcc version installed + boost 1.49. I removed all gcc but last 4.7 version and boost (to be sure only internal LO Boost 1.44 is used) + ccache -C. So it's building right now from a clean install (I even removed my local LO master sources directory and git cloned again)
By reading this, http://cboard.cprogramming.com/cplusplus-programming/104911-elements-iterator-range-%5B__first-__last-not-partitioned.html it seems the crash may only be triggered in debug mode. Thorsten: just noticed o3tl part in the bt, would you have some time to take a look? This in particular: /usr/include/c++/4.7/bits/stl_algo.h:2676:error: elements in iterator range [__first, __last) are not partitioned by the predicate __comp and value __val. Objects involved in the operation: iterator "__first" @ 0x0x7fff0ca6bae0 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPKP9SwTxtAttrNSt9__cxx19986vectorIS4_SaIS4_EEEEENSt7__debug6vectorIS4_S9_EEEE (constant iterator); state = dereferenceable (start-of-sequence); references sequence with type `NSt7__debug6vectorIP9SwTxtAttrSaIS2_EEE' @ 0x0x7fff0ca6bae0 } iterator "__last" @ 0x0x7fff0ca6bab0 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPKP9SwTxtAttrNSt9__cxx19986vectorIS4_SaIS4_EEEEENSt7__debug6vectorIS4_S9_EEEE (constant iterator); state = past-the-end; references sequence with type `NSt7__debug6vectorIP9SwTxtAttrSaIS2_EEE' @ 0x0x7fff0ca6bab0 }
Julien, I shall take a look. But my development machine is off the net, and my local library will soon be closed until Wednesday; so any thoughts I get will be delayed. Yes, one of my recent bug reports--I cannot find it at the moment--definitely came up because STL iterators do more checking in debug mode. I apologize if I am even less coherent than usual. Watching the clock and preparing to be kicked out. Terry.
I can reproduce the bug in master commit eaf3c60, pulled 2012-12-18, configured as --enable-dbgutil --enable-crashdump --disable-build-mozilla --without-system-postgresql --without-myspell-dicts --without-help --with-extra-buildid built and running on ubuntu-natty (11.04) 32-bit. My backtrace is quite similar to Julien's, and valgrind shows nothing very interesting.
(In reply to comment #7) > Thorsten: just noticed o3tl part in the bt, would you have some time to take > a look? > Seems that CompareSwpHtEnd is not behaving as to what equal_range expects.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c59355e936446fe55960209e543b072acb6b2170 fdo#58793: re-implement SwpHintsArray::Resort(): 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cdd0555aefa0a01d0d90fed8640811c5601f314e&h=libreoffice-4-0 fdo#58793: re-implement SwpHintsArray::Resort(): It will be available in LibreOffice 4.0. 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.
problem is that SwpHintsArray::Resort uses sorted_vector::insert to re-sort the vector which became un-sorted by various other code, and insert relies on it being sorted already...
d'oh FIXED it was
Put it at VERIFIED, thank you Michael!