Bug 80448 - FILEOPEN: openGL init crashes Calc
Summary: FILEOPEN: openGL init crashes Calc
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.3.0.1 rc
Hardware: Other All
: high major
Assignee: xukai
URL:
Whiteboard: target:4.4.0
Keywords: bibisected, regression
Depends on:
Blocks: OpenGL mab4.4 81107
  Show dependency treegraph
 
Reported: 2014-06-24 01:29 UTC by Yousuf Philips (jay) (retired)
Modified: 2015-12-17 08:24 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
backtrace on linux (28.89 KB, text/plain)
2014-06-24 01:32 UTC, Yousuf Philips (jay) (retired)
Details
backtrace on windows (3.24 KB, text/plain)
2014-06-24 01:35 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2014-06-24 01:29:20 UTC
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.
Comment 1 Yousuf Philips (jay) (retired) 2014-06-24 01:30:20 UTC
File loaded successfully in 4.2.4 on Windows and 4.2.5 on Linux Mint.
Comment 2 Yousuf Philips (jay) (retired) 2014-06-24 01:32:33 UTC
Created attachment 101619 [details]
backtrace on linux
Comment 3 Yousuf Philips (jay) (retired) 2014-06-24 01:35:15 UTC
Created attachment 101620 [details]
backtrace on windows
Comment 4 Florian Reisinger 2014-06-24 13:13:59 UTC
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
Comment 5 Florian Reisinger 2014-06-24 13:18:09 UTC
Also present on Win 7 x64 with Version: 4.3.0.0.beta1
Build-ID: b7cfa1eab1cb1e94f71d6df6612b73f231d0bf92
Comment 6 Julien Nabet 2014-06-24 20:46:09 UTC
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.
Comment 7 Joel Madero 2014-07-09 05:21:43 UTC
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
Comment 8 Michael Meeks 2014-07-09 10:53:10 UTC
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 ...
Comment 9 Markus Mohrhard 2014-07-10 11:01:23 UTC
(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.
Comment 10 Michael Meeks 2014-07-10 11:20:05 UTC
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.
Comment 11 Markus Mohrhard 2014-07-10 11:25:31 UTC
(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.
Comment 12 Michael Meeks 2014-07-10 12:35:53 UTC
makes sense - so a dup then - thanks ! =)

*** This bug has been marked as a duplicate of bug 81055 ***
Comment 13 Tamás Zolnai 2014-07-15 12:31:52 UTC
Looking into back traces it seems to me that we can't handle it together with fdo#81055.
Comment 14 Joel Madero 2014-07-15 15:04:48 UTC
Reopened only if the bug is assigned to someone and has been declared fixed by that developer. Setting to NEW
Comment 15 Michael Meeks 2014-07-16 15:45:58 UTC
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.
Comment 16 Markus Mohrhard 2014-07-18 17:18:50 UTC
(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.
Comment 17 Björn Michaelsen 2014-08-21 12:21:14 UTC Comment hidden (obsolete)
Comment 18 Markus Mohrhard 2014-08-27 17:09:11 UTC
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.
Comment 19 Yousuf Philips (jay) (retired) 2014-08-28 01:11:51 UTC
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.
Comment 20 Commit Notification 2014-09-07 17:38:20 UTC
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.
Comment 21 Michael Meeks 2014-09-10 14:44:50 UTC
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 !
Comment 22 Markus Mohrhard 2014-09-10 14:50:47 UTC
(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.
Comment 23 Michael Meeks 2014-09-10 19:30:25 UTC
Thanks Markus - over to you Jay ... =)
Comment 24 Yousuf Philips (jay) (retired) 2014-09-10 22:15:33 UTC
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.
Comment 25 Michael Meeks 2014-09-11 09:50:13 UTC
Great - thanks Jay: marking fixed.
Comment 26 Robinson Tryon (qubit) 2015-12-17 08:24:13 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]