Bug 84356 - LO CALC will crash when open a document which contain a chart
Summary: LO CALC will crash when open a document which contain a chart
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Chart (show other bugs)
(earliest affected)
Hardware: Other All
: medium normal
Assignee: Not Assigned
Keywords: bibisected
Depends on:
Blocks: 81107
  Show dependency treegraph
Reported: 2014-09-26 07:48 UTC by xukai
Modified: 2015-12-15 11:03 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

The document I want to open (1.58 MB, application/zip)
2014-09-26 07:48 UTC, xukai

Note You need to log in before you can comment on or make changes to this bug.
Description xukai 2014-09-26 07:48:23 UTC
Created attachment 106902 [details]
The document I want to open

Export UNLOCK_FPS_MODE=1 and open the document. The window will twinkle and then crash.

I record a video to show how to reproduce this bug, the link is as follow:


I also upload the document that I want to open.
Comment 1 Terrence Enger 2014-09-26 18:41:06 UTC

Please tell us what version of LibreOffice shows the problem and what
platform you are using.

Note, most importantly, that I am *assuming* that my crash, with
terminal messages:

    /usr/include/c++/4.8/debug/safe_iterator.h:293:error: attempt to increment 
        a singular iterator.

    Objects involved in the operation:
    iterator "this" @ 0x0x7f5f8a065cd0 {
    type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPPvNSt9__cxx19986vectorIS3_SaIS3_EEEEENSt7__debug6vectorIS3_S7_EEEE (mutable iterator);
      state = singular;
      references sequence with type `NSt7__debug6vectorIPvSaIS1_EEE' @ 0x0x3146ce8
    Application Error

    Fatal exception: Signal 6

sheds light on the reporter's problem.  Unless xukai is running a
dbgutil build, I think that the original crash cannot be exactly the
same as mine.

From the command line, I opened:

    CalcExtDemo\ -\ V10.0/Calc_Demo_Version10.0.ods

from the attached .zip file.  When prompted to enable macros, I denied

From the daily dbgutil bibisect repository, `git bisect good`:

    cfa0d940ef43e42c4315a778e55d6e8b1dea6291 is the first bad commit
    commit cfa0d940ef43e42c4315a778e55d6e8b1dea6291
    Author: Miklos Vajna <vmiklos@collabora.co.uk>
    Date:   Wed Sep 24 08:19:14 2014 +0200


    :100644 100644 be1e40744a3c050f5d3ffc34a4f297b352aaeaad 3ec4cb9def917337567fff4fcddb68769ea732ab M	build-info.txt
    :040000 040000 08bcc4b6fd44c06aacac1efe917b25cefb9e9c10 ab70ff29b5c3c0d2329db446ab6d080e2512d706 M	opt

and `git bisect log`:

    # bad: [89d418aefe6115554b888c334ec405487baf9cda] 2014-09-26
    # good: [b3130c846de5cf1b4be48b48dfc780bb369549fa] 2014-05-21
    git bisect start 'origin/master' 'oldest'
    # good: [78882e6831ce98a1b061c9656b4fc3565cfa2e04] 2014-07-24
    git bisect good 78882e6831ce98a1b061c9656b4fc3565cfa2e04
    # good: [f5043baf54256feb23ca38332261eaad621d0c21] 2014-08-25
    git bisect good f5043baf54256feb23ca38332261eaad621d0c21
    # good: [3a6614ba47a0729e3d6c31588b850ca11ae4a6b5] 2014-09-10
    git bisect good 3a6614ba47a0729e3d6c31588b850ca11ae4a6b5
    # good: [1aae1687a0a30f933f1326596def39e3f094d9ea] 2014-09-18
    git bisect good 1aae1687a0a30f933f1326596def39e3f094d9ea
    # good: [38e21a9d721c77604167367bd2fca4b0e8a21944] 2014-09-22
    git bisect good 38e21a9d721c77604167367bd2fca4b0e8a21944
    # bad: [cfa0d940ef43e42c4315a778e55d6e8b1dea6291] 2014-09-24
    git bisect bad cfa0d940ef43e42c4315a778e55d6e8b1dea6291
    # good: [df3b0ca62028d5327e209d1aeb7dd4895be8b24f] 2014-09-23
    git bisect good df3b0ca62028d5327e209d1aeb7dd4895be8b24f
    # first bad commit: [cfa0d940ef43e42c4315a778e55d6e8b1dea6291] 2014-09-24

Comment 2 xukai 2014-09-28 02:04:38 UTC
The crash is caused by thread conflict. Following patch introduce this issue:
I suspect the patch has not been verified before commit.
The issue can be resolved if I add thread synchronization logic in my work environment.
Comment 3 Michael Meeks 2014-09-29 08:38:50 UTC
Hmm, my fault for rubber stamping this I think; lets go over this together when you get in Kohei =)
Comment 4 Michael Meeks 2014-09-29 16:37:26 UTC
Thanks for the clean report; confirming etc. & taking a look.
Comment 5 Michael Meeks 2014-09-29 19:55:11 UTC
Ah; you have to export SCROLL_RATE=100 as well or somesuch.
Re-adding the lock there appears to make life better; I've committed that to master; thanks.
Really we shouldn't have the chart mutex locked while we're in SwapBuffers AFAICS - it'd be the ideal time to re-build the chart model in another thread then while the GL drivers are doing their stuff.

Then again - the new, faster Windows main-loop, my hope would be that we could get a nice high FPS here without resorting to the over-complicated and fragile threading.
Comment 6 xukai 2014-09-30 05:41:31 UTC
Some other things which are not easy to be notice must still exist. It works fine if we don't enable the data updating, but it will crash and not smooth if we enable the data updating.
Comment 7 Robinson Tryon (qubit) 2015-12-15 11:03:29 UTC
Migrating Whiteboard tags to Keywords: (bibisected)