@xukai,

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
permission.


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

        2014-09-24

    :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


Terry.

The crash is caused by thread conflict. Following patch introduce this issue:
http://cgit.freedesktop.org/libreoffice/core/commit/chart2/source/view/charttypes/GL3DBarChart.cxx?id=3a4f5b47222a399d0745c4ae5eb000f4e75a7041
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.

Hmm, my fault for rubber stamping this I think; lets go over this together when you get in Kohei =)

Thanks for the clean report; confirming etc. & taking a look.

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.

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.

Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]