Bug #664
Segmentation fault on video playback
Status: | Fixed | Start date: | 08/29/2011 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | % Done: | 100% | ||
Category: | GLW | |||
Target version: | 4.0 | |||
Found in version: | 3.1.210.g26900 | Platform: |
Description
I tried to confirm another bug i have on the ps3 and ran into this issue on my laptop. When i try to play a video (it doesn't mater what kind of video) showtime segfaults. Maybe this is an issue of my crapy intel graphics card. To build showtime on my machine i changed the configure script to exept an older version of ffmpeg. By looking at the stacktrace and some debugger output I don't think this is related, but you never know.
I use Gentoo Linux amd64.
I will monitor this bug in case more feedback is needed.
Before submit i did some additional debuging. The Segfault rises in this line in glw_opengl.c
544: glUniform4f(gbr->gbr_current->gp_uniform_color, r, g, b, a);
The problem is, that in my case gbr_current is 0. The compiler translates this part of the code to
MOV RAX, QWORD PTR [RDI+8] <- at RDI+8 is a 0 were should be the pointer to gbr_current
MOV RDI, DWORD PTR [RAX+28] <- this trys to get gp_uniform_color but RAX is 0 so it trys to load a value from 001c with is not mapped and causes a segfault.
I tried to find the cause for this, but it seems that opengl code is even harder to read than assemly.
Related issues
Associated revisions
History
#1
Updated by Andreas Smas over 11 years ago
This is a known issue. :/
#2
Updated by Robin Nehls over 11 years ago
I'm sorry i could not find an existing issue for this. Could you post a link so i can participate in case i find something usefull?
#3
Updated by Andreas Smas over 11 years ago
Ok sorry I meant that this is a known "problem". I'm not sure if there is a filed issue for it.
#4
Updated by Andreas Smas over 11 years ago
- Status changed from New to Accepted
- Target version set to 33
#5
Updated by Robin Nehls over 11 years ago
I did some more diging in the code. Looks like the code were the segfault happens is highly dependant on shader stuff, with is disabeld in glw_opengl_init_context for Mesa OpenGL drivers. Removing the Mesa check worked for me only once. Videos played, but had smal blue dots in them. After closing showtime I could not make it work again. Strange.
So the problem seems to be an missing implementation for shaderless playback, witch leeds me to the conclusion that you already know what i just wrote. Sorry for the nagging.
#6
Updated by Henrik Andersson almost 11 years ago
I just stumble upon this bug and as mentioned before shaders are disabled if Mesa driver
is used and down the rendering code path shaders a expected to work even if disabled as
stated in earlier comments.
With about zero knowledge about shaders and Mesa compatibility i just removed the check
and got glw ui to work ?!
GLW [INFO]: OpenGL Renderer: 'Mesa DRI Intel(R) G45/G43 ' by 'Tungsten Graphics, Inc'
If the non-shader codepath is "broken" / "uncomplete" it should not take that road
especially if there is a possibility the Mesa driver + shaders works, my suggestion is to
remove the Mesa check and add some log output that the user is on a experimental road..
diff --git a/src/ui/glw/glw_opengl_ogl.c b/src/ui/glw/glw_opengl_ogl.c index 0b7875b..33409d1 100644 --- a/src/ui/glw/glw_opengl_ogl.c +++ b/src/ui/glw/glw_opengl_ogl.c @@ -175,9 +175,6 @@ glw_opengl_init_context(glw_root_t *gr) int use_shaders = 1; - if(strstr(renderer, "Mesa")) - use_shaders = 0; - if(use_shaders) { return glw_opengl_shaders_init(gr); } else {
#7
Updated by Andreas Smas over 10 years ago
- Status changed from Accepted to Fixed
- % Done changed from 0 to 100
Applied in changeset 5ca9af925e558927e48d5c6e4a29d554c5b8043f.
#8
Updated by Andreas Smas over 10 years ago
- Target version changed from 33 to 4.0