[Linux] Failed to setup Skia Gr context in some configurations #170
Comments
|
Note that (2) could be very useful, and doesn't require much set-up, just patience to try re-testing with a bunch of versions of the Flutter tree. For anyone trying, even if you don't isolate it as far as possible, if you find any flutter hash that works for you, please post that hash and a hash that fails for you, so that narrowing the range can potentially be done collaboratively. |
|
I successfully built flutter-desktop-embedding and the linux example, is my machine information relevant? If so you need the output from which commands? P.S: I don't know if is relevant for this issue, but the example ran with 100% of one of my cores. |
Currently we need debugging/information from people who have the crash, which it doesn't sound like is the case for you.
That's issue #58. |
|
I've just finished testing each release of flutter until I found one that worked. It would seem something in v0.9.6 of flutter is the culprit (at least for me) as v0.9.5 and the handful of releases I tested before that all work fine. A few notes:
Let me know if there's any other info I can provide. If I have some time, I'll try digging deeper into the the changes between these two versions, but hopefully this is a good starting point for someone else to investigate the issue. |
|
Thanks for the investigation! That range includes flutter/engine#6353, so that's the point where you'd hit #135. Have you tried bdc3dda5f298f50b432faaffe71730c4fe26afda (or anything shortly after that point), when the fix for #135 went in? While an obvious possible explanation is that that something about that didn't work for some graphics configuration, it's also possible that the fix did work, but then there was a later regression. |
|
For more info, here's the stack trace using a locally built engine. I'm still tracking it down but hopefully this might be useful for other folks to find the culprit. |
|
The crash is almost certainly a symptom of the context being null; the critical question is what happened to cause rather than the crash itself. |
|
I can confirm the finding by @ciiqr. I'm running Ubuntu 18.04 minimal installation. I have manually installed X11, lightdm and am using xmonad as window manager. xmonad is a tiling window manager, which is something that 'awesome wm' used by @ciiqr may do as well. I have seen some applications break when they can't resize themselves or when a tiling window manager resizes them to fit their appointed tile. However, I configured my xmonad to let the application float, which should allow it to resize itself to any size it wants. The application still breaks (after shortly popping on screen). So it doesn't seem to be related to non-floating, but may still be related to the non-standard window managers doing something that others don't. I used this config in the xmonad manage hook to float the window: I saw in the mentioned commits that the changes were mostly about OpenGL vs OpenGL ES? I'm not a native C++ speaker so I don't think I'll be able to properly debug this. But perhaps this information is interesting: $ glxinfo -v | grep "OpenGL"
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 1070/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 396.54
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6.0 NVIDIA 396.54
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 396.54
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:Another thing: I'm running a 4K display. This may seem a bit far-fetched, but there are still quite a few applications on linux that have trouble on HiDPI displays. The display is rendered natively at |
|
@stuartmorgan Sorry I forgot to mention this. I tried |
|
I have now setup local engine development (after hacking my way through install scripts, because ubuntu 18.04 isn't supported) and am trying to see what values I get for that OpenGL ES detection. I'm thinking it may have to do with nvidia driver? Is there anything you'd recommend to try? @stuartmorgan |
|
edit: The error above (in strikethrough) seems to be unrelated to the Skia context stuff. I updated |
In GrGLInterface.cpp: if (fExtensions.has("GL_EXT_window_rectangles")) {
if (!fFunctions.fWindowRectangles) {
RETURN_FALSE_INTERFACE;
}
}In my case, the interface being validated was created by skia's I'm going to stop trying to figure this out further as we seem to be heading into the realm of Skia. The complex C++ there is way above my head as I never work with C++, and have almost no experience with GL either. But I hope this information helps whomever may continue this . |
That's already #160 Thanks for the added details; I'll take a look at that Skia code when I get a chance and see where the function that is missing (if that's the line that returned failure) would be populated |
|
@stuartmorgan, I think I have the same issue and switching from my nvidia card to the integrated card made it not crash |
|
I couldn't let it go and got a small bit further. Found that indeed the symbol could not be resolved to set |
|
I have a fix locally. Working on a PR now. |
Fixes #170 The default symbol resolver that is used when no specific resolver is given doesn't resolve according to OpenGL features available in the GLFW context. This causes errors for some users.
|
I have the same error ("Failed to setup Skia Gr context") despite making sure I have all the dependencies. I have the latest beta engine version ("7375a0f414bde4bc941e623482221db2fc8c4ab5"). I am running KDE neon on my computer and can provide more information if needed. |
|
Please file a new issue, since the specific cause that was being tracked here was fixed, so what you are seeing would be something different. |
With recent builds, some people are seeing persistent "Failed to setup Skia Gr context" logging + crash on startup.
Unlike the previous instance (#135), this does not affect all Linux configurations, only some, which suggests this may be driver related, or capability-related. For instance, in at least one instance I'm aware of the crash happens when using a machine normally, but not when using Chrome Remote Desktop to access the same machine.
Things that could be useful from people experiencing this:
(3) would be the most useful, but is obviously the most involved. I believe @franciscojma86 will be trying this route.
The text was updated successfully, but these errors were encountered: