Bug 58793 - FILEOPEN: Crash when trying to open attachment fdo#58277
Summary: FILEOPEN: Crash when trying to open attachment fdo#58277
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.0.0.alpha0+ Master
Hardware: Other Linux (All)
: high major
Assignee: Michael Stahl
QA Contact:
URL:
Whiteboard: BSA target:4.1.0 target:4.0.0.2
Keywords: regression
Depends on:
Blocks:
 
Reported: 2012-12-27 06:57 UTC by Julien Nabet
Modified: 2013-08-18 17:31 UTC (History)
5 users (show)

See Also:


Attachments
bt + console logs on master (14.76 KB, text/plain)
2012-12-27 06:57 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Nabet 2012-12-27 06:57:09 UTC
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
Comment 1 Julien Nabet 2012-12-27 06:58:22 UTC
Increase importance since it's a crash + regression
Comment 2 Jorendc 2012-12-27 11:09:34 UTC
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
Comment 3 Jorendc 2012-12-27 11:15:25 UTC
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.
Comment 4 tommy27 2012-12-28 19:28:49 UTC
not reproducible on Windows Vista 64bit using
Version 4.0.0.0.beta2+ (Build ID: 350ae8294a8df78403fd8cdce56b9aeb8178e13)
Comment 5 Marco Menardi 2012-12-29 21:12:56 UTC
Debian GNU/linux 64, Libo 4.0beta2, can't reproduce, file opens just fine, I can scroll it, the close it without problems.
Comment 6 Julien Nabet 2012-12-30 09:39:25 UTC
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)
Comment 7 Julien Nabet 2012-12-30 14:15:40 UTC
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
}
Comment 8 Terrence Enger 2012-12-30 19:04:01 UTC
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.
Comment 9 Terrence Enger 2013-01-03 03:16:22 UTC
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.
Comment 10 Thorsten Behrens (CIB) 2013-01-10 17:48:04 UTC
(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.
Comment 11 Not Assigned 2013-01-11 10:33:18 UTC
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.
Comment 12 Not Assigned 2013-01-11 10:44:12 UTC
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.
Comment 13 Michael Stahl 2013-01-11 10:49:53 UTC
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...
Comment 14 Michael Stahl 2013-01-11 10:50:13 UTC
d'oh FIXED it was
Comment 15 Julien Nabet 2013-01-11 21:30:33 UTC
Put it at VERIFIED, thank you Michael!