Closed
Bug 660466
Opened 13 years ago
Closed 13 years ago
Segmentation Fault glxtest.cpp:172
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla7
People
(Reporter: kdevel, Assigned: bjacob)
References
Details
(Keywords: regression)
Attachments
(2 files)
976 bytes,
patch
|
karlt
:
review+
jst
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
987 bytes,
patch
|
karlt
:
review+
jst
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
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
Updated•13 years ago
|
Blocks: 639842
Component: General → Graphics
Keywords: regression
Product: Firefox → Core
QA Contact: general → thebes
Comment 1•13 years ago
|
||
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.
Post hoc. s/crashes due to/crashes after/ The browser crashed due to a glib issue.
Assignee | ||
Comment 3•13 years ago
|
||
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.
Attachment #535966 -
Flags: review?(karlt)
Updated•13 years ago
|
Attachment #535966 -
Flags: review?(karlt) → review+
(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.
Assignee | ||
Comment 5•13 years ago
|
||
Attachment #536212 -
Flags: review?(karlt)
Updated•13 years ago
|
Attachment #536212 -
Flags: review?(karlt) → review+
Assignee | ||
Comment 6•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/2b48445cd5be http://hg.mozilla.org/mozilla-central/rev/569aed0a1d49
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•13 years ago
|
Attachment #535966 -
Flags: approval-mozilla-aurora?
Assignee | ||
Comment 7•13 years ago
|
||
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.
Attachment #536212 -
Flags: approval-mozilla-aurora?
Updated•13 years ago
|
Assignee: nobody → bjacob
Target Milestone: --- → mozilla7
Updated•13 years ago
|
Attachment #535966 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Updated•13 years ago
|
Attachment #536212 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Comment 9•13 years ago
|
||
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
status-firefox6:
--- → fixed
tracking-firefox6:
--- → +
Comment 10•13 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•