Bug 57513 - xlock unlocks by itself
xlock unlocks by itself
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: xlockmore (Show other bugs)
7.1
alpha Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-12-14 13:27 EST by Robert M. Riches Jr.
Modified: 2008-05-01 11:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-16 14:46:22 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)

  None (edit)
Description Robert M. Riches Jr. 2001-12-14 13:27:00 EST
Description of Problem:
xlock spontaneously exits, unlocking the display.  This usually
happens some number (5-60) of minutes after starting xlock.

Version-Release number of selected component (if applicable):
xlockmore-4.17.2-2 on RH7.1, fully updated as of 12/13/01

How Reproducible:
about 25% with lock durations on the order of a half hour to
an hour

Steps to Reproduce:
1. invoke /usr/X11R6/bin/xlock (no arguments)
2. wait 5-60 minutes or so
3. 

Actual Results:
xlock spontaneously exits, leaving the display unlocked.
It gives the following messages:

Access control list restored.
xlock.wrap: caught signal 8 while running invert mode (uid 501).

Expected Results:
xlock should continue to run and keep the display locked until
the password is entered or until it is terminated

Additional Information:
Comment 1 Harald Hoyer 2002-01-08 09:22:10 EST
seems like 3D is broken on your system (libGL.so???)
Comment 2 Robert M. Riches Jr. 2002-01-08 23:33:01 EST
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.)
Comment 3 Harald Hoyer 2002-01-09 05:48:23 EST
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 ;)
Comment 4 Robert M. Riches Jr. 2002-01-09 15:10:53 EST
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?
Comment 5 Harald Hoyer 2002-01-15 09:25:39 EST
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
???
Comment 6 Robert M. Riches Jr. 2002-01-15 13:09:23 EST
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?
Comment 7 Robert M. Riches Jr. 2002-01-15 13:24:22 EST
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.
Comment 8 Robert M. Riches Jr. 2002-01-16 14:46:17 EST
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.

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