Bug 83633 - FILESAVE: Crash when save in ODF 1.0/1.1
Summary: FILESAVE: Crash when save in ODF 1.0/1.1
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.4.0.0.alpha0+ Master
Hardware: All All
: highest major
Assignee: Caolán McNamara
URL:
Whiteboard: target:4.4.0
Keywords: bisected, haveBacktrace, regression
Depends on:
Blocks: mab4.4
  Show dependency treegraph
 
Reported: 2014-09-08 22:22 UTC by Regina Henschel
Modified: 2014-09-14 14:03 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
gdb on the core file (14.94 KB, text/plain)
2014-09-09 20:29 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2014-09-08 22:22:52 UTC
Start with new spreadsheet and enter some values.
Set file format to ODF "1.0/1.1" in Tools > Options > Load/Save > General
Button "Save", enter filename, save.
=> Crash
It does not matter, which file dialog you use.

I see the error in: 
Version: 4.4.0.0.alpha0+
Build ID: aa0e3701aad1a8a955773e869d9a6b59eac51e72
TinderBox: Win-x86@39, Branch:master, Time: 2014-08-10_07:00:24
and in:
Version: 4.4.0.0.alpha0+
Build ID: 5aeb852efcabdd51545d5d41c92f4bf3cef1d663
TinderBox: Win-x86@39, Branch:master, Time: 2014-09-08_07:01:57

It does not crash in:
Version: 4.4.0.0.alpha0+
Build ID: aa453de65b8b44f9c1e6012caaeef11df9ff65fc
TinderBox: Win-x86@39, Branch:master, Time: 2014-05-24_13:45:34
Comment 1 Terrence Enger 2014-09-09 04:10:10 UTC
This crash seems to have come into LibreOffice in the range covered by
the daily dbgutil bibisect repository.  From `git bisect bad`:

    3c19bff344aa6109cdd40e5ab4986a95ecdd7542 is the first bad commit
    commit 3c19bff344aa6109cdd40e5ab4986a95ecdd7542
    Author: Miklos Vajna <vmiklos@collabora.co.uk>
    Date:   Thu Jul 3 09:23:47 2014 +0200c

        2014-07-03

    :100644 100644 7978c6649b507a5e933d1044156e855691389bbe e3f723fefc307d67bace9192f131da52d8b05ac4 M	build-info.txt
    :040000 040000 d2e27a624bdbf7fdaf180168b898515ef2c069e5 b3e03a61fb86cb7b111312eef6b12589186b155a M	opt

and from `git bisect log`:

    # bad: [bc8fe1433f6f3c946571d2c65d2d58553efbd9c6] 2014-09-05
    # good: [b3130c846de5cf1b4be48b48dfc780bb369549fa] 2014-05-21
    git bisect start 'bc8fe14' 'oldest'
    # bad: [a5750a3c0c5d3b975a787f844d7ba60db53a765e] 2014-07-13
    git bisect bad a5750a3c0c5d3b975a787f844d7ba60db53a765e
    # good: [fa158998e0a0c735a13384def1ba902f904fab22] 2014-06-16
    git bisect good fa158998e0a0c735a13384def1ba902f904fab22
    # good: [998f4b7ef8a3213b3cb94628acd93fa624f9268c] 2014-06-29
    git bisect good 998f4b7ef8a3213b3cb94628acd93fa624f9268c
    # bad: [b195929c45dca218e941073bcb5bcaa92d21d7f7] 2014-07-06
    git bisect bad b195929c45dca218e941073bcb5bcaa92d21d7f7
    # good: [b7ea5ebd0e0fee42d8971dd75b8efbc6e0e47739] 2014-07-02
    git bisect good b7ea5ebd0e0fee42d8971dd75b8efbc6e0e47739
    # bad: [14df9828a18e82c76c275e74351d6fca8f015c55] 2014-07-04
    git bisect bad 14df9828a18e82c76c275e74351d6fca8f015c55
    # bad: [3c19bff344aa6109cdd40e5ab4986a95ecdd7542] 2014-07-03
    git bisect bad 3c19bff344aa6109cdd40e5ab4986a95ecdd7542
    # first bad commit: [3c19bff344aa6109cdd40e5ab4986a95ecdd7542] 2014-07-03

So, the range of source commits is 4f90623..6c4e21a.


I ran the bisect in a chroot environment to debian-sid 64-bit, so
setting platform "All, All".
Comment 2 Terrence Enger 2014-09-09 20:29:41 UTC
Created attachment 106009 [details]
gdb on the core file

Along with that backtrace, consider this extract from the terminal
output:

    /usr/include/c++/4.7/debug/safe_iterator.h:292:error: attempt to increment 
        a past-the-end iterator.

    Objects involved in the operation:
    iterator "this" @ 0x0x7fff7b50c6b0 {
    type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPK16XMLPropertyStateNSt9__cxx19986vectorIS3_SaIS3_EEEEENSt7__debug6vectorIS3_S8_EEEE (constant iterator);
      state = past-the-end;
      references sequence with type `NSt7__debug6vectorI16XMLPropertyStateSaIS1_EEE' @ 0x0x2eeee18
    }
    Application Error

    Fatal exception: Signal 6

This observation is in a chroot envionment to debian-sid 64-bit; the
LibreOffice is master commit f74a633, fetched 20-14-08-23, configured:
    --enable-option-checking=fatal --enable-dbgutil --enable-crashdump
    --without-system-postgresql --without-myspell-dicts
    --with-extra-buildid --without-doxygen
    --with-external-tar=/home/terry/lo_hacking/git/src
    --enable-online-update
built on debian-wheezy 64-bit

For contrast, the same build of LibreOffice executing in debian-wheezy
with the same user actions fails with a segmentation fault deep in
system libraries.  The first part of LibreOffice in the backtrace is:

    #33 0x00007fdf890ec371 in GtkData::Yield (this=0x213f0e0, bWait=false, bHandleAllCurrentEvents=true) at /home/terry/lo_hacking/git/libo2/vcl/unx/gtk/app/gtkdata.cxx:575
Comment 3 Terrence Enger 2014-09-09 20:40:31 UTC
Added to MAB 4.4; correspondingly setting priority Highest.
Comment 4 Commit Notification 2014-09-14 14:02:53 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9fecabec60d63b2b5eefafc81308f13f770e67b9

Resolves: fdo#83633 remove additional ++i



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.