Last Comment Bug 660466 - Segmentation Fault glxtest.cpp:172
: Segmentation Fault glxtest.cpp:172
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: mozilla7
Assigned To: Benoit Jacob [:bjacob] (mostly away)
:
: Milan Sreckovic [:milan]
Mentors:
Depends on:
Blocks: 639842
  Show dependency treegraph
 
Reported: 2011-05-28 12:32 PDT by Stefan
Modified: 2011-08-12 09:03 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
fixed


Attachments
check if any fbconfig was found (976 bytes, patch)
2011-05-29 15:39 PDT, Benoit Jacob [:bjacob] (mostly away)
karlt: review+
jst: approval‑mozilla‑aurora+
Details | Diff | Splinter Review
check if a visual was found (987 bytes, patch)
2011-05-30 19:48 PDT, Benoit Jacob [:bjacob] (mostly away)
karlt: review+
jst: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Stefan 2011-05-28 12:32:16 PDT
User-Agent:       
Build Identifier: 

Shortly after the main window has been painted, the browser crashes due to null ptr deref in glxtest.cpp:172

    171   GLXFBConfig *fbConfigs = glXChooseFBConfig(dpy, DefaultScreen(dpy), at        tribs, &numReturned );
    172   XVisualInfo *vInfo = glXGetVisualFromFBConfig(dpy, fbConfigs[0]);

(gdb) p fbConfigs
$2 = (GLXFBConfig *) 0x0


Reproducible: Always
Comment 1 Karl Tomlinson (back Dec 13 :karlt) 2011-05-28 18:02:30 PDT
That looks like it is a bug, but a crash there shouldn't bring down the whole browser, because this test code is meant to run in a (forked) separate process.
Comment 2 Stefan 2011-05-29 04:19:05 PDT
Post hoc. s/crashes due to/crashes after/
The browser crashed due to a glib issue.
Comment 3 Benoit Jacob [:bjacob] (mostly away) 2011-05-29 15:39:02 PDT
Created attachment 535966 [details] [diff] [review]
check if any fbconfig was found

It's not clear to me if and why this can be any related to the Firefox process crash you're mentioning, but in any case it does seem that we should check if glXChooseFBConfigs returned null.
Comment 4 Stefan 2011-05-30 01:48:41 PDT
(In reply to comment #3)
> It's not clear to me if and why this can be any related to the Firefox
> process crash you're mentioning, 

When FF crashed I started a gdb session which stopped in glxtest.cpp:172 but this was not the cause of the FF crash. FF crashed when and because the mouse cursor touched the FF window. After replacing the glib the seg fault in glxtest.cpp is successfully reported under Troubleshooting Information/Graphics

> but in any case it does seem that we should
> check if glXChooseFBConfigs returned null.

Return from glXGetVisualFromFBConfig should be checked, too.
Comment 5 Benoit Jacob [:bjacob] (mostly away) 2011-05-30 19:48:41 PDT
Created attachment 536212 [details] [diff] [review]
check if a visual was found
Comment 7 Benoit Jacob [:bjacob] (mostly away) 2011-06-10 13:58:01 PDT
Comment on attachment 536212 [details] [diff] [review]
check if a visual was found

These are 2 tiny patches, that fix issues with code first introduced in FF6, so I think it would be nice to take in Aurora.
Comment 8 christian 2011-06-28 13:25:03 PDT
Please land this on releases/mozilla-aurora today
Comment 9 Benoit Jacob [:bjacob] (mostly away) 2011-06-28 13:30:06 PDT
That landed yesterday, sorry I forgot to paste the links here:
http://hg.mozilla.org/releases/mozilla-aurora/rev/a0c6fa6eca26
http://hg.mozilla.org/releases/mozilla-aurora/rev/65000fbcdb45
Comment 10 AndreiD[QA] 2011-08-12 09:03:17 PDT
Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0

I was trying to see if this is fixed for Fx6 since the flag "status-firefox6" is set on "fixed", but I couldn't.
Is there a test case or any steps / guidelines for this bug that can be used to verify the fix? Thanks

Note You need to log in before you can comment on or make changes to this bug.