Created attachment 122012 [details] screen clip of SEH exception fatal error On Windows 10 Pro 64-bit en-US both with and without OpenGL enabled on Version: 5.1.0.2 (x64) Build ID: ecd3574d51754b043f865cf5bafee286d24db7cc CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Locale: en-US (en_US) An Impress presentation open, and slide transitions deck active in SideBar. Choosing the Shape group, and selecting Diamond throws fatal SEH Exception: Access Violation. Same slide, and Shape group but selecting Plus, or Circle has no issue.
Created attachment 122027 [details] WinDbg backtrace Hello, and thank you for bringing this issue to our attention. I can reproduce the described behaviour reliably: 1. Open new Impress document 2. Click on Slide Transition on the right-hand side 3. Choose the Shape transition, wait for the animation to end 4. In Modify Transition, use the drop-down menu Variant and choose Diamond. 5. SEH Exception: ACCESS VIOLATION The last version to work reliably that I've tested is 5.0.4.2, the issue was introduced somewhere after. I will add a backtrace with this comment - I had some problems with the symbols though, hope it's still good. Setting status to NEW. -- Windows 10 Pro, Version 1511 (OS Build 10586.36)
*** Bug 97489 has been marked as a duplicate of this bug. ***
From my duplicate bug. linux backtrace - attachment 122319 [details] Version: 5.2.0.0.alpha0+ Build ID: 513d5c5781ec14f8512432f31290a3d54c8d57df CPU Threads: 2; OS Version: Linux 4.2; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-02-01_10:25:20 Locale: en-US (en_US.UTF-8)
LibreOffice Impress 5.1.0.3 crash after selecting slide transition "Shape" with variant "Diamond" with no error in openSUSE 13.2 Linux: I only see black window.
Emmanuel - may be interesting to you; not GL related directly but ... =)
Narrowed this down a little, needs a proper bibisect Somewhere between 2015-12-14 and 2015-12-31 https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=121b7b880c4d17c1ce320ad6b1c560577c9953ed..fe37d93a110cb9941c61fed0c71369a21a7d2765
(In reply to V Stuart Foote from comment #6) > Narrowed this down a little, needs a proper bibisect > > Somewhere between 2015-12-14 and 2015-12-31 > > https://cgit.freedesktop.org/libreoffice/core/log/ > ?qt=range&q=121b7b880c4d17c1ce320ad6b1c560577c9953ed.. > fe37d93a110cb9941c61fed0c71369a21a7d2765 @raal, @xisco: Could one of you do a bibisect for this to further narrow down where it started.
This seems to have begun at the below commit. Adding Cc: to Emmanuel Gil Peyrot; Could you possibly take a look at this one? Thanks aa5d9651141bc7a6a7f7bceae7e6d0d7e07db363 is the first bad commit commit aa5d9651141bc7a6a7f7bceae7e6d0d7e07db363 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Tue Jan 5 12:09:29 2016 -0800 source a301da7cb6c562cd21983d9b3b34dc01235a82a5 source a301da7cb6c562cd21983d9b3b34dc01235a82a5 :040000 040000 aacfb1d99ce74b309399d35abb283bd79f285dd2 c1b977597284ab5d1220ed2bd7d4704ef2bd0e38 M instdir author Emmanuel Gil Peyrot <emmanuel.peyrot@collabora.com> 2015-12-21 21:25:35 (GMT) committer Tomaž Vajngerl <tomaz.vajngerl@collabora.com> 2016-01-05 14:05:49 (GMT) commit a301da7cb6c562cd21983d9b3b34dc01235a82a5 (patch) slideshow: Define inverse() to bring back the GLSL version to 1.20
SEH Exception crash with us still on Windows 8.1 Pro 64-bit en-US with Version: 5.1.1.2 (x64) Build ID: fe4d9e69c82c6ee6db3c27cd5e2d47558afa80ac CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL; Locale: en-US (en_US) SEH Exception with or without OpenGL rendering enabled, and when in Presentation mode or while editing.
@Stuart: The feb 24th and after crash is reported in bug 98175.
(In reply to Yousuf (Jay) Philips from comment #10) > @Stuart: The feb 24th and after crash is reported in bug 98175 Understood it affects all on master with hard crash > 24 Feb; but issue here of the shape -> diamond transition SEH crash remains with the 5.1.1 pre-release
The trace is a clear duplicate here; thanks for reporting =) *** This bug has been marked as a duplicate of bug 98175 ***
Created attachment 123210 [details] WinDbg backtrace after fix for bug 98175 applied Reopening. The Diamond shape transition continues to crash with SEH error even with patch for bug 98175 applied. On Windows 8.1 Pro 64-bit en-US with Version: 5.2.0.0.alpha0+ Build ID: 7ccdb94e2c5774f924bf89b34387c7d41e2e4c30 CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-03-03_02:40:45 Locale: en-US (en_US)
Created attachment 123673 [details] stack trace with TB39 32-bit build symbols The Diamond shape transition continues to crash with SEH error, 32-bit/64-bit builds with and without OpenGL rendering enabled. Is there an error implementing the algorithm calculating steps of the transition? On Windows 8.1 Ent 64-bit en-US Version: 5.1.2.1 (x64) Build ID: 2603b69c5ec5981bb5f053f8ebfd1f3de00a4c29 CPU Threads: 8; OS Version: Windows 6.29; UI Render: default; (or GL) Locale: en-US (en_US) Version: 5.2.0.0.alpha0+ Build ID: 6eb7cd38e348e8a9d6498bfc2d41e91725eb34aa CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-03-16_12:53:35 Locale: en-US (en_US) Stack trace with symbols attached from the TB39 build.
No crash here with diamond transition using Office 32bit on win7 (no OpenGL activated): Version: 5.2.0.0.alpha0+ Build ID: 4331b137fdbe6992ca63ceb70a6f48ed6f9a86ea CPU Threads: 8; OS Version: Windows 6.1; UI Render: GL; Locale: de-DE (de_DE) Not sure about the bug description, tried: - new impress, delete text frames - draw a shape, keep selected - on custom animation in sidebar, press '+' and add 'Diamond' - also add others (forth and back), with and without automatic preview If another sequence is needed to reproduce, please describe in more detail
(In reply to Armin Le Grand (CIB) from comment #15) > ... > Not sure about the bug description, tried: > - new impress, delete text frames > - draw a shape, keep selected > - on custom animation in sidebar, press '+' and add 'Diamond' > - also add others (forth and back), with and without automatic preview > > If another sequence is needed to reproduce, please describe in more detail Here are STR: 1. new impress slide 2. sidebar: Properties -> blank slide layout 3. Insert -> Image 4. pick a random PNG or JPEG, resize if preferred 5. sidebar: Slide Transition -> Shape transition default Shape transition is Plus -- on selection will preview the effect 6. sidebar: Slide Transition: Modify Transition: Variant -> displays Plus the combobox list offers "Plus" (default), "Diamond", "Circle" 7. select Circle, the circle transition effect will apply 8. select Plus, the plus transition effect will apply 8. select Diamond--what happens? "SEH Exception: ACCESS VIOLATION" crash on all builds I've tested, stack trace attached.
Got the crash now, thanks for the complete reproduction steps. It crashes after OGLTransitionImpl::displaySlidesince since m_nFirstIndices.cbegin() is called and handed to displayPrimitives, but m_nFirstIndices is empty. In displayPrimitives, std::vector<int>::const_iterator first is dereferenced and leads to crashes. The vector docu says to cbegin(): "If the container is empty, the returned iterator value shall not be dereferenced." I do not know what slideshow should do here. It may be that m_nFirstIndices being empty is the error, it may be that using it is the error. Adding thb at cc...
With 'plus' and 'Circle' OGLTransitionImpl::displaySlide is not called, only with 'Diamond'. Trying to simply 'secure' access to m_nFirstIndices and see if that works...does not, no animation shown. Thus the error seems to be that m_nFirstIndices is empty. It gets filled in OGLTransitionImpl::prepare, uploadPrimitives call where getScene().getLeavingSlide() uses an empty primitvie vector. Someone knowing more baout slideshow needs to take a look.
Seems to be a MSVC compiler error. The loop for (const Primitive& primitive: primitives) is used three times in slideshow\source\engine\OGLTrans\generic\OGLTrans_TransitionImpl.cxx. In 'displayPrimitives' it executes it's body even with empty vector, that way '*first++' gets dereferenced and crashes.
May have been too fast with that - only *looked* like calls were done, seems more a source level debugger error in positioning the cursor. Stepping through assembler looks better. maLeavingSlidePrimitives and maEnteringSlidePrimitives is empty when the transition is prepared, that seems wrong. Later, TransitionScene::operator= is called and a new Scene with maLeavingSlidePrimitives and maEnteringSlidePrimitives == 1 is set. Probably parts of 'uploadPrimitives' has to be done again - or the correct entzer/leaves have to be present in preparation (aka earlier).
Made a quick check, also crashes on fresh master Linux build.
I do not now enough about these transitions and how they are intended to work - who does this and can please take over?
*** Bug 98855 has been marked as a duplicate of this bug. ***
Created attachment 124234 [details] stack trace 64-bit 5.1.2.2 release build symbols So, with 64-bit 5.1.2.2 release also the same SEH Exception access violation. Same STR when changing Slide transition Shape variant from Plus or Circle to Diamond. stack trace with 64-bit symbols attached.
Created attachment 125195 [details] stack trace with symbols current TB39 master On Windows 10 Pro 64-bit en-US with Version: 5.2.0.0.alpha1+ Build ID: 7b704dfbdb23540ff6366fa60c73474bbda9dc26 CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-05-20_05:45:40 Locale: en-US (en_US) Posted another stack trace with symbols (Kendy's TB39) Aborting in OGLTrans_TransitionImpl.cxx @ 298 http://opengrok.libreoffice.org/xref/core/slideshow/source/engine/OGLTrans/generic/OGLTrans_TransitionImpl.cxx?a=true#298 Does the diamond/iris transition code do something silly for the diamond configuration?
Where this goes wrong is straight forward, how to fix it I'm not so sure though. OGLTransitionImpl::prepare is initially called, that calls uploadPrimitives and sets m_nFirstIndices, i.e. m_nFirstIndices = uploadPrimitives(getScene().getLeavingSlide()); later on void DiamondTransition::prepare calls... setScene(TransitionScene(aLeavingSlidePrimitives, aEnteringSlidePrimitives)); and the *old* scene has no primitives, so the m_nFirstIndices is empty the *new* scene has 1 primitive, so later on displayPrimitives understandably crashes because there is a primitive without a corresponding index.
Created attachment 125326 [details] this makes it not crash, but results in no visible transition
Diamond transition is still causing an SEH Exception close... Version: 5.2.0.1 (x64) Build ID: fcbcb4963bda8633ba72bd2108ca1e802aad557d CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Locale: en-US (en_US)
David Tardon committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c726059adf71f9c812df3363b4902c52023827b6 tdf#97195 fix crash in diamond shape transition It will be available in 5.3.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.
This is a blind fix, as OpenGL transitions fail to work on my machine since 5.1, but after backport into 5.0 the transition continues to work. Could someone verify on master?
doesn't crash, so that's a plus, I don't get a visible transition though :-(. Just black, then bam, the slide.
On Windows 8.1 Ent 64-bit en-US with Version: 5.3.0.0.alpha0+ Build ID: b0d96a82a4f6a0832d03d185f4a53db669adcc99 CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2016-07-12_09:25:31 Locale: en-US (en_US); Calc: CL No crash, but same black only transition before slide appears.
A comment before where uploadPrimitive() were called interest me, // In practice both leaving and entering slides share the same primitives. Going over all the TransitionScene use cases, only a few abide.
David Tardon committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a0d3168ee4ac202790f1d4d0c95a6264cc8bf455 tdf#97195 make diamond transition work again It will be available in 5.3.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.
(In reply to Commit Notification from comment #34) > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=a0d3168ee4ac202790f1d4d0c95a6264cc8bf455 > > tdf#97195 make diamond transition work again On Windows 8.1 Ent 64-bit en-US with Version: 5.3.0.0.alpha0+ Build ID: 7b86ff8c8a791ddf80d07be3f5309fb889c3f8be CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-07-19_10:08:28 Locale: en-US (en_US); Calc: CL So with this build, we do have general diamond transition effect. Unfortunately, the effect is not very smooth. With or without OpenGL rendering the expanding diamond has noticeable tessellation with large gores flashing black. With OpenGL rendering enabled it grows from center to upper left and then fills, in default it expands more equally from center--but also with noticeable triangle glitches. Might need a little tuning yet.
David Tardon committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=439df080e7e82908cd80e01ca1b3a03ddb3ac8ec&h=libreoffice-5-2 tdf#97195 fix crash in diamond shape transition It will be available in 5.2.1. 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.
David Tardon committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=55fee3e981f5c2b901d7bdbbf8965f434cbea7ff&h=libreoffice-5-2 tdf#97195 make diamond transition work again It will be available in 5.2.1. 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.
*** Bug 83875 has been marked as a duplicate of this bug. ***
Is this fix verified? (I can't because any slide transition on 5.2 crashes LO Win7 64bit.)
I wonder if this matter is explained here: https://bugs.documentfoundation.org/show_bug.cgi?id=103046#c12
Yes the crash is verified fixed, but visual artifacts in the diamond transition on Windows builds, as in comment 35. The effect could still use some adjustment.
I believe https://cgit.freedesktop.org/libreoffice/core/commit/?id=579feb4d841ea80de699f4124378d0701034833e will address #35
(In reply to Caolán McNamara from comment #42) > I believe > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=579feb4d841ea80de699f4124378d0701034833e will address #35 Yes it does, the Diamond transition is smooth now.