Bug 57513

seems like 3D is broken on your system (libGL.so???)

I don't understand from the comment what is needed?  What
information do you need?  I'm running RH7.1 plus up2date
updates through 1/5/02.  I'm running version 4.03-21 of
the XFree86 family.  The only thing not straight from the
book I have done with X is to install the 3.3.6 servers
in a failed attempt to get 24-bit color at 1600x1200 with
at least one of the graphics cards I have.

When I look for files called *libGL* on the system, I find
the following:

/usr/lib/libGL.so.1
/usr/lib/libGL.so.1.2.030402
/usr/lib/libGLU.so.1
/usr/lib/libGLU.so.1.1.030402
/usr/lib/libGL.a
/usr/lib/libGL.la
/usr/lib/libGL.so
/usr/lib/libGLU.a
/usr/lib/libGLU.la
/usr/lib/libGLU.so
/usr/X11R6/lib/modules/extensions/libGLcore.a

What additional information is needed?  (I have worked with
people who would move a bug to "needinfo" just to improve
the weekly statistics the boss looks at.  Surely that wouldn't
happen at Redhat.)

statistics do not mean anything to me... ;)
so, your xlock dies in invert mode. are you able to 
$ xlock -mode invert
??
Does 3D function properly? Just another NEEDINFO ;)

Thanks for the clarification of what you needed.
Doing "xlock -mode invert" worked fine three times
in a row, at least for several seconds.  At least
basic 3D/GL capability seems to be working.  The
rapidly-generated polygons, colliding galaxies, and
morphing polyhedra looked good.  When I hit a key
to unlock, the background was white rather than the
usual black, but I'm guessing that what "invert"
means.

What other information or testing will help in trying
to resolve this problem?

hmm, when I do 
$ xlock -mode invert -nolock
it shows a golden ball morphing into a violet one.. no screen invertion or 
other things involved...

other 3D modes work also??? like 
$ xlock -mode pipes -nolock
???

I tried the indicated command five times:

    /usr/X11R6/bin/xlock -mode pipes -nolock

Each time, the screen remained blank for a few seconds then showed the
expected screenful of nicely rendered randomly routed pipes, fittings,
gauges, and valves.  The pipes come in different colors and are very
nicely shaded.

As I tried to state before, xlock is capable of displaying any of
the modes/scenes, or so it appears, for at least a few minutes.  The
problem is a random failure (always catching "signal 8 while running
invert mode") usually somewhere between 5 and 20 minutes after
invoking xlock.

Are there additional commands, modes, combinations of switches you
want me to try?

Oops.  Egg on my face!  I apologize for having been clueless.
I had forgotten about an alias I had made that was dropping
command-line switches.  Once the alias is gone, I get more
illuminating results:

"xlock -mode pipes -nolock" gives very nice displays of
shaded piping.

"xlock -mode invert -nolock" immediately (and consistently)
gives a Floating exception.

When the distributed binary was compiled, was the "-mieee"
switch given to the compiler?  I have seen several programs
that require this compilation switch on Alpha, or they give
floating point exceptions.  Apparently, some functions or
opcodes produce denormalized FP results, doing gradual
underflow.  The exp() function with arguments more negative
than about -670 or so seem to do this.  When that denormalized
number is later used, an exception happens.  The -mieee
compilation switch causes the exception to be trapped and/or
the denormalized numbers to be converted to zero or something
nicer.

So, 3D rendering works fine.  The invert mode blows up with
a floating point exception, immediately and consistently.

One workaround would be to manually specify a mode.  Another
thing I might look into if I run out of critical things to do
is to rebuild from the SRPM, inserting the -mieee compilation
switch.  Unfortunately, I don't believe I will be able to get
to trying this.

Perhaps for future releases, it would be helpful to use the
-mieee compilation switch for programs that are likely to cause
strange close-to-zero numbers.

I tried to validate my theory that the -mieee switch would
solve the problem.  I installed the source RPM from the CD
(xlockmore-4.17.2-2.src.rpm), unpacked the tarball into a
sandbox, applied the c++ and inplicit patches, and compiled
it.  This binary would do pipes and gave the FP exception
with invert mode.

Then, I added -mieee to CFLAGS and CXXFLAGS in all Makefiles
that set those variables.  This has eliminated the FP exception.
Now, "./xlock/xlock -mode invert -nolock" produces a 3D star-
shaped thing with yellow, purple, and grey wings, some with a
texture of some sort.  It rotates about 1 frame per second,
which I'm guessing is due to a massive number of FP traps and
the fix-up routine.  The -mieee option must be added to CXXFLAGS,
just adding it to CFLAGS is not sufficient.

So, I think I will put this xlock in /usr/local/bin for now.
Any future releases of FP-intensive code such as this should
probably use the -mieee switch for the Alpha architecture.