Bug 54491

Are you sure you have en_US not en.encoding which is an invalid locale?
I think the bug is basically that gdm sets an invalid locale, which results in
fontsets breaking, which is then compounded by sawfish not expecting its fonts
to fail to load.

*** Bug  54105 has been marked as a duplicate of this bug. ***

*** Bug 52500 has been marked as a duplicate of this bug. ***

*** Bug 52107 has been marked as a duplicate of this bug. ***

I printed the environment to check when reporting the bug LANG was set to en_US.
This was startx run rather than gdm in case its relevant. The box has been
everything since about 6.0 or so

After getting the latest version from sawfish.sourcefore.net (1.0.1-1) and
upgrading the standard RedHat sawfish with it, the problem
disappeared for me on a RedHat 7.2 release system.(This also envolved getting
more recent versions of librep and readline) and some rpm -Uvh --force 's to
convince rpm gently that the new RPMS really were newer.

The reason it works is that you lose the Red Hat patch causing the problem when
you upgrade. The problem patch sets a font which doesn't load for some reason.

*** Bug 55220 has been marked as a duplicate of this bug. ***

There's now a fixed package in ftp://people.redhat.com/hp/gnomehide and one 
should appear in rawhide soon. But it probably breaks CJK, so the fix 
isn't really quite right.

*** Bug 56405 has been marked as a duplicate of this bug. ***

One report on testers-list (Paul Iadonisi, mail has "56405" in subject)
that the bug happens only when LANG is unset and startx is used to start
X; with gdm LANG is set properly so no bug.

Still need to track down why we get a system with no LANG, and why 
the XLFD we had in Sawfish failed to load with the locale unset.

Paul used kickstart to install the systems.

*** Bug 60101 has been marked as a duplicate of this bug. ***

I have found that this bug (or a very similar one) still affects sawfish under
Red Hat Linux 7.2

I'm using the x386 architecture and have kept up to date with the RH72 errata. I
am also using gdm and have not unset LANG.

I have found a few preconditions (all must be satisfied)
- gdm should set the locale to C/POSIX. en_US and en_AU does NOT trigger the bug
- the sawfish configuration must define the move-show-position and
error-destination.
- No other files (not even ~/.bash*) are needed in the user's home directory.

The effect I've observed is that any attempt to move a window will cause an
infinite of beeps and a keyboard lockup. If the user is quick enough, they can
change to a virtual terminal before lockup. Otherwise, sawfish can also be
killed via a remote login or reboot.

I have also replicated (as per bug-history) this bug by starting X from a
virtual terminal with LANG unset. The bug also occurs when X is started from a
virtual terminal with LANG=C

I have not included the contents of ~/.sawfish/custom but can do so if required.

Does the sawfish at the gnomehide url work for you?

It's quite simple really; if the locale is oddball, sawfish can't load the
default font added for 7.2. Sawfish beeps and aborts the current operation when
it has an error, such as failing to load fonts.

*** Bug 60474 has been marked as a duplicate of this bug. ***

*** Bug 57754 has been marked as a duplicate of this bug. ***

*** Bug 53943 has been marked as a duplicate of this bug. ***

Yes sawfish-1.0.1-1 and dependencies resolved all known problems.

So is there going to be an update to Red Hat 7.2 to fix this?  Not having the
ability to resize windows is quite a serious drawback in a window manager.  And
locking up my system, as happened yesterday, is an even more serious drawback.

Run the localeconfig tool and that should sort the problem out after you
restart again. The problem isnt so much sawfish as incorrectly set country
codes.

Sawfish can't freeze your machine - can you file that as a seperate bug and it
can get looked at too.

Alan

As Alan says, AFAIK it only breaks if your locale isn't set.

Locking up the system is not something Sawfish can do, that is either an X or
kernel bug typically.

1.0.1-5 should resolve this issue. 

For CJK, the issue is still unresolved because translations for the fonts need
to go in.

I did a bit more investigation after Alan's suggestion of reporting the
system lockup as a X fault.

To clarify, on one of my system (the one other system I've tested on is
unaffected) when one moves a window using an older version of sawfish
(eg 0.38-11), sawfish starts emitting a never-ending stream of beeps.
As a result, it also locks up the keyboard. If one is quick enough
(sub-second), one can switch to a virtual terminal, otherwise, the only
way to get shell is remotely (eg ssh). Regardless, the beeping (via the
internal PC speaker) continues.

A ``top'' while the system is beeping will reveal that it is sawfish
consuming most of the CPU cycles. With the X server consuming the rest
(20%). So I decided to attach a gdb session while sawfish was running.
I then observed that if I suspended sawfish from gdb, I could return to
my X session at will without any keyboard lockups. Indeed, I was able
to continue using my current X processes (eg xterm) and even start new
X processes (as discovered via ps) -- with the cavet that no new
windows would be displayed as the window manager was suspended.

If I then killed sawfish, I could then return to my X session at will,
starting new processes and generally using the computer, just without a
window manager. Therefore, any keyboard lockups were only temporary.
Indeed, I could (within X) start a new sawfish session which would work
perfectly fine -- other than the abovementioned bugs like moving windows.

To me, it doesn't sound like a X bug at all. Can someone (alan/hp?)
confirm that this is still a X (or kernel) bug? And if so, what details
could I possibly include in the bug report?

AFAIK this was never a kernel bug, just Sawfish getting a bad font. The Sawfish
in Rawhide should be entirely fixed.