While working on bug 80393, i noticed that if i loaded < https://drive.google.com/file/d/0B3J2r6UWSeZ4bHF5b1lJUGtvT0E/edit?usp=sharing > into 4.3 or 4.4, it will crash. Tested in Linux Mint and Windows 7.
File loaded successfully in 4.2.4 on Windows and 4.2.5 on Linux Mint.
Created attachment 101619 [details] backtrace on linux
Created attachment 101620 [details] backtrace on windows
Not crashing in Version: 4.2.1.1 Build-ID: d7dbbd7842e6a58b0f521599204e827654e1fb8b Very long loading times (resulting in HANG and crash) with Version: 4.4.0.0.alpha0+ Build ID: bdd87b2acddb2e244569dcc8f228e270614dc59e TinderBox: Win-x86@39, Branch:master, Time: 2014-06-23_00:37:24 and Version: 4.3.0.1 Build-ID: 67f5430184326974072b65403ef1d9d934fc4481 Setting priority according to https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
Also present on Win 7 x64 with Version: 4.3.0.0.beta1 Build-ID: b7cfa1eab1cb1e94f71d6df6612b73f231d0bf92
On pc Debian x86-64 with master sources updated today, it takes some time to load but I don't reproduce the crash. I noticed the presence of this log several times: warn:chart2:24284:1:chart2/source/view/main/ShapeFactory.cxx:2132: Exception caught. Type: N3com3sun4star3uno9ExceptionE, Message: With 4.2 sources updated 3 days ago, I don't reproduce the crash either and there's not the logs quoted above.
a900e72b6357882284c5955bdf939bf14269f5fb is the first bad commit commit a900e72b6357882284c5955bdf939bf14269f5fb Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Sun May 11 22:39:43 2014 +0000 source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07 commit dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07 Author: Stephan Bergmann <sbergman@redhat.com> AuthorDate: Mon Mar 10 10:47:17 2014 +0100 Commit: Stephan Bergmann <sbergman@redhat.com> CommitDate: Mon Mar 10 17:39:51 2014 +0100 Deprecate com.sun.star.XTypeProvider.getImplementationId ...now that no client code should remain that depends on non-empty sequences. Change-Id: I91a8e8e14ae4a652a32ca4e76e1228de58f71633 :100644 100644 ea96a0526310063bde21923d70f4fa8a33c0dbc4 77185d3877a81343add56c45db97c9aae2399533 M ccache.log :100644 100644 262bf2e11cbd9f76479f5594fd5a3fb1e53c4967 38e0f923bfcb9f392dbbb6f5e6f27a7f3ef09460 M commitmsg :100644 100644 e3c3207390a08b6ab0e55ea902d0f41599a0c0cb 7418e0adc397c19264987c13d88166449c6f73ce M make.log :040000 040000 bb344f1b5623f2f2b3c70ac8faba85c5a362582c ced9862f1b11dcd9b70e508265dcd8f8c7d0fd12 M opt # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b git bisect good 4850941efe43ae800be5c76e1102ab80ac2c085d # bad: [a900e72b6357882284c5955bdf939bf14269f5fb] source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07 git bisect bad a900e72b6357882284c5955bdf939bf14269f5fb # good: [e1d0365cd2b073a859f59ad0a4584385a66dc611] source-hash-2eea96c702a44ab009743b0d22ef639127f0b57b git bisect good e1d0365cd2b073a859f59ad0a4584385a66dc611 # skip: [8f55938c891ee3e4c252b193dba9419f130537bc] source-hash-93f3f72d18e551c8edd6a010cb78d9cbe404f8ef git bisect skip 8f55938c891ee3e4c252b193dba9419f130537bc # good: [7518fcaf863962bf4f6f3cdf84f6e42f0f59225f] source-hash-ab1f5eab4830f00dbbd7c883b98b59975ecd3bb1 git bisect good 7518fcaf863962bf4f6f3cdf84f6e42f0f59225f # good: [56a3b3c781fc2eb55f46641d89a866a91119a8a3] source-hash-21e6fd2b2dfdb806db320f699e434e6f2351a7b6 git bisect good 56a3b3c781fc2eb55f46641d89a866a91119a8a3 # good: [0b79394752f7ecbab6ab4ecedbfab8551c6e9fbd] source-hash-381613916d42a1e18e2824b5d41028dcfe19659a git bisect good 0b79394752f7ecbab6ab4ecedbfab8551c6e9fbd # good: [33ce87ec76b69b6a44704835916642ad3ad1539a] source-hash-2be3417bf6dba2a0897b21e15d22ef2f8aac99e3 git bisect good 33ce87ec76b69b6a44704835916642ad3ad1539a # first bad commit: [a900e72b6357882284c5955bdf939bf14269f5fb] source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07
Oh; nasty - the trace looks like this: program/../program/libvclopengllo.so #10 0xb054e90b in OpenGLWindowImpl::OpenGLWindowImpl(SystemChildWindow*) () from /home/jay/Downloads/software/office/LibO betas/LibreOfficeDev_4.3.0.0.beta1_Linux_x86_deb/DEBS/install/opt/libreofficedev4.3/program/../program/libvclopengllo.so #11 0xb054e97a in OpenGLWindow::OpenGLWindow(Window*) () from /home/jay/Downloads/software/office/LibO betas/LibreOfficeDev_4.3.0.0.beta1_Linux_x86_deb/DEBS/install/opt/libreofficedev4.3/program/../program/libvclopengllo.so #12 0x942ebcb8 in ScTabViewShell::AddOpenGLChartWindows() () from /home/jay/Downloads/software/office/LibO betas/LibreOfficeDev_4.3.0.0.beta1_Linux_x86_deb/DEBS/install/opt/libreofficedev4.3/program/../program/libsclo.so #13 0x942f0d94 in ScTabViewShell::Initialize() () from /home/jay/Downloads/software/office/LibO betas/LibreOfficeDev_4.3.0.0.beta1_Linux_x86_deb/DEBS/install/opt/libreofficedev4.3/program/../program/libsclo.so #14 0xb772b3a0 in SfxBaseController::initializ Markus - any ideas on this ? The document looks like it has only standard (non GL) charts inside it; so my hope would be that we can avoid doing any OpenGL initialization and hitting this GLChartWindows stuff (?) Seems like a plain OpenGL init crashes that machine: nasty ...
(In reply to comment #8) > Oh; nasty - the trace looks like this: > > program/../program/libvclopengllo.so > #10 0xb054e90b in OpenGLWindowImpl::OpenGLWindowImpl(SystemChildWindow*) () > from /home/jay/Downloads/software/office/LibO > betas/LibreOfficeDev_4.3.0.0.beta1_Linux_x86_deb/DEBS/install/opt/ > libreofficedev4.3/program/../program/libvclopengllo.so > #11 0xb054e97a in OpenGLWindow::OpenGLWindow(Window*) () from > /home/jay/Downloads/software/office/LibO > betas/LibreOfficeDev_4.3.0.0.beta1_Linux_x86_deb/DEBS/install/opt/ > libreofficedev4.3/program/../program/libvclopengllo.so > #12 0x942ebcb8 in ScTabViewShell::AddOpenGLChartWindows() () from > /home/jay/Downloads/software/office/LibO > betas/LibreOfficeDev_4.3.0.0.beta1_Linux_x86_deb/DEBS/install/opt/ > libreofficedev4.3/program/../program/libsclo.so > #13 0x942f0d94 in ScTabViewShell::Initialize() () from > /home/jay/Downloads/software/office/LibO > betas/LibreOfficeDev_4.3.0.0.beta1_Linux_x86_deb/DEBS/install/opt/ > libreofficedev4.3/program/../program/libsclo.so > #14 0xb772b3a0 in SfxBaseController::initializ > > Markus - any ideas on this ? The document looks like it has only standard > (non GL) charts inside it; so my hope would be that we can avoid doing any > OpenGL initialization and hitting this GLChartWindows stuff (?) > > Seems like a plain OpenGL init crashes that machine: nasty ... He only has OpenGL 1.4 which is way too old so it comes down to our missing code for checking that the OpenGL concepts are supported. I'm not even sure how you are able to have only an OpenGL 1.4 capable GPU anymore.
Ah - so a dup of bug#81055 ? but I wonder whether we really should be initializing GL unless we are certain that we truly need it ? surely that is to ask to enter a world of pain ? =) Then again if we're going to move to more GL code in 4.4 then perhaps it's a good starting point.
(In reply to comment #10) > Ah - so a dup of bug#81055 ? but I wonder whether we really should be > initializing GL unless we are certain that we truly need it ? surely that is > to ask to enter a world of pain ? =) Then again if we're going to move to > more GL code in 4.4 then perhaps it's a good starting point. It reduces complexity. If we know that an OpenGL context and a corresponding window are always available we can avoid quite some of the lifecycle pain around OpenGL and vcl Windows. We can of course go back to trying to understand all the different lifecycles and debug horrible corner cases for weeks. I hope that with Tamas' work we are able to move a step closer to a better lifecycle handling but in general it looks like we currently live better if we always initialize OpenGL together with the window. Detecting when an OpenGL method is called is not obvious and makes all the logic more complex.
makes sense - so a dup then - thanks ! =) *** This bug has been marked as a duplicate of bug 81055 ***
Looking into back traces it seems to me that we can't handle it together with fdo#81055.
Reopened only if the bug is assigned to someone and has been declared fixed by that developer. Setting to NEW
Thanks Tamaz - we fixed this for 4.3 by disabling 3D charts there, but I suspect we're waiting for the cleaned up drawinglayer version on master for 4.4 before unwinding this; I'll update the blocks.
(In reply to comment #15) > Thanks Tamaz - we fixed this for 4.3 by disabling 3D charts there, but I > suspect we're waiting for the cleaned up drawinglayer version on master for > 4.4 before unwinding this; I'll update the blocks. I'm still not sure what might be going wrong there except for broken drivers. glXCreateContext may only crash if something in your X Server goes wrong. I'm not aware of any way we can screw this up. I might to read some old GLX spec but I'm not aware of any fancy glx features that are used in the OpenGL context part.
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting libreoffice qa on irc: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
I'm not sure why this is a MAB. This looks like a driver bug for exactly one person. IMHO this does not even remotely qualify as a MAB bug unless several people are affected.
Well i have Linux Mint on my 2008 desktop and Windows 7 on my 2007 laptop, both running on the inbuilt intel graphics card which has OpenGL 1.4 support. I dont know how wide spread this will effect users, but i'd assume any user running a Windows Vista-era or prior desktop/laptop without a dedicated graphics card would be effected by this. This is not just effecting one person as Florian has also confirmed this in comment 4. It would be good to know what OpenGL version and graphics card Florian is running to see how likely it is to effect users. It also has to be taken into consideration that most users are still running 4.1 or 4.2, as 4.3 is only a month old and if they upgraded and things crashed, they would downgrade.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=19be6cfc93eb4f7d0b4440c42f698805294fb881 prevent crash with invalid XVisual, related fdo#80448 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.
Unclear if this still persists; if this is use of un-checked GL extensions that are not present; and/or how to proceed here. Jay - can you reproduce with master on Windows ? it should be worked around in 4.3 by Markus. Jay - can you give more details on your exact graphics card & driver version ? =) Thanks !
(In reply to comment #21) > Unclear if this still persists; if this is use of un-checked GL extensions > that are not present; and/or how to proceed here. > > Jay - can you reproduce with master on Windows ? it should be worked around > in 4.3 by Markus. Jay - can you give more details on your exact graphics > card & driver version ? =) > > Thanks ! I hope I fixed that one already. I think the old driver does not provide a format that we request and therefore creating a context fails. I added a check for that case and return that we are not supporting OpenGL in that case. Checking that my assumption is correct is appreciated.
Thanks Markus - over to you Jay ... =)
I tested it on 4.3 and 4.4 on my Windows 7 Laptop and it didnt crash. Version: 4.4.0.0.alpha0+ Build ID: 7af850c89664d3c739abd244cb7016b806c0f293 TinderBox: Win-x86@39, Branch:master, Time: 2014-09-10_06:38:46 Version: 4.3.2.0.0+ Build ID: c6b46c2c23ba883a83bc8a6fdf3a37d2a9ffbf95 TinderBox: Win-x86@42, Branch:libreoffice-4-3, Time: 2014-09-06_20:17:18 Here is the opengl info for the laptop. Renderer: Intel 945GM Vendor: Intel Memory: 256 MB Version: 1.4.0 - Build 8.14.10.1930 Shading language version: N/A Here is the opengl info for my desktop. $ glxinfo | grep OpenGL OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) G33 x86/MMX/SSE2 OpenGL version string: 1.4 Mesa 9.2.0 Unfortunately i cant test it there as there hasnt been any new daily builds of @45-TDF in over a week. Now that this is completed, it would be good to look into the slow performance that happens when opening this document (mentioned in comment 4 and comment 6), as well as the crash reported in bug 80393 for deleting a sheet.
Great - thanks Jay: marking fixed.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]