Bug 7691 – GL screensavers crash

Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 7691 - GL screensavers crash

Summary:	GL screensavers crash

Status:	CLOSED RAWHIDE

Aliases:	None

Product:	Red Hat Raw Hide
Classification:	Retired
Component:	xscreensaver (Show other bugs)
Sub Component:
Version:	1.0
Hardware:	All Linux

Priority	medium Severity high
Target Milestone:	---
Target Release:	---
Assigned To:	Bill Nottingham
QA Contact:
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	1999-12-08 18:19 EST by Brian Ryner
Modified:	2014-03-16 22:11 EDT (History)
CC List:	1 user (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2000-01-18 12:00:49 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Brian Ryner 1999-12-08 18:19:32 EST

I'm not sure if this is a problem with xscreensaver or with glxMesa.
Whenever I try to use one of the GL screensavers (I tried with atlantis and
bubble3d), it segfaults.  I got the following stack trace from gdb:

Program received signal SIGSEGV, Segmentation fault.
0x40032d4a in glx_send_client_info () from /usr/X11R6/lib/libGL.so.1
(gdb) where
#0  0x40032d4a in glx_send_client_info () from /usr/X11R6/lib/libGL.so.1
#1  0x40058708 in ?? () from /usr/X11R6/lib/libGL.so.1

I'm running XFree86-3.3.5-15 (SVGA server), Diamond Viper 330 (Riva128).

Comment 1 Bill Nottingham 1999-12-08 18:29:59 EST

You need to add:

Section "Module"
        Load "glx.so"
EndSection

to your /etc/X11/XF86Config (and restart the server, of course).

Dunno how well the Riva128 is supported by the new glxMesa stuff.
(only testing here has been with G200).

Comment 2 Bill Nottingham 1999-12-08 18:30:59 EST

Yes, the glx stuff should probably exit more gracefully
if the server module isn't there, though...

Comment 3 Brian Ryner 1999-12-08 20:00:59 EST

That didn't work... it caused X to crash on startup with this error:

Fatal server error:
Caught signal 4.  Server aborting


When reporting a problem related to a server crash, please send
the full server output, not just the last messages

X connection to :0.0 broken (explicit kill or server shutdown).

Comment 4 Bill Nottingham 1999-12-09 12:40:59 EST

What processor do you have?

Comment 5 Brian Ryner 1999-12-09 12:43:59 EST

Pentium/MMX 233 MHz.

Comment 6 Bill Nottingham 1999-12-15 16:50:59 EST

Out of curiousity, what happens if you rebuild the SRPM
and install it on your own machine?

Comment 7 Bill Nottingham 1999-12-15 16:51:59 EST

(that's the glxMEsa source RPM.)

Comment 8 Brian Ryner 1999-12-17 18:36:59 EST

Well, I rebuilt from the 19991206-3 SRPM, and I have a question regarding your
previous instructions to add:

Section "Module"
        Load "glx.so"
EndSection

to XF86Config.  Now, this file is only in the -devel RPM.  Shouldn't that go in
the main package RPM?

Comment 9 Brian Ryner 1999-12-17 19:00:59 EST

By the way, rebuilding the package on my machine seems to have solved the
segfault.  Unfortunately, it looks like I'm not getting accelerated 3d on my
Riva128.  I'm going to look into that, it looks like there is some support in
glxMesa that can be turned on.

Comment 10 Bill Nottingham 1999-12-20 13:59:59 EST

OK, looks like the configure script is being stupid and
specifying -march=i686 when built on a PII/PIII (which
our build machine is...).

We'll get this fixed. Possibly we should build both i686
and i386 packages.

Comment 11 Bill Nottingham 2000-01-18 12:00:59 EST

This has been fixed in the glxMesa packges, and in the
distribution as the latest Raw Hide ships with software
Mesa only.

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