Bug 47650 - system hangs on xdvi
system hangs on xdvi
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-07-06 08:48 EDT by Rutger Noot
Modified: 2005-10-31 17:00 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-03-14 07:06:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
result of strace xdvi rubin (127.54 KB, text/plain)
2001-07-06 08:50 EDT, Rutger Noot
no flags Details
tarfile of confuguration to reproduce bug (30.00 KB, application/x-tar)
2001-07-11 08:24 EDT, Rutger Noot
no flags Details
XFree86 configuration file (1.53 KB, text/plain)
2001-10-29 12:34 EST, Rutger Noot
no flags Details
Xfree log file (deleted)
2001-10-29 12:38 EST, Rutger Noot
no flags Details
Xfree log file (deleted)
2001-10-29 12:40 EST, Rutger Noot
no flags Details
XFree86 log file (deleted)
2001-10-29 12:46 EST, Rutger Noot
no flags Details
XFree log file (deleted)
2001-10-29 15:05 EST, Rutger Noot
no flags Details
XFree log file (22.92 KB, text/plain)
2001-10-30 04:35 EST, Rutger Noot
no flags Details

  None (edit)
Description Rutger Noot 2001-07-06 08:48:43 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.51 [en] (X11; I; Linux 2.2.16-3 sparc64)

Description of problem:
Changing the shrink factor while viewing a file with xdvi make 
_the entire system_ hang. 
This may actually be a kernel bug... 

How reproducible:

Steps to Reproduce:
1. xdvi rubin  (rubin.dvi is a file in 10pt created by plain tex)
2. change the shrink factor like so 6s 5s 4s 3s

Actual Results:  system hangs completely! Screen is frozen, cannot switch
consoles, can't kill X (by Ctr-Alt-Backspace), telnet connection 
to the machine is frozen as well. No response to ping requests

Expected Results:  I would of course expect the size of my charaters to
change on screen,
but at worst a crash of xdvi, not a complete lockup. 

Additional info:

1. The problem does not occur when xdvi is run with display on
another machine
2. The problem also happens with a brand new xdvi from CTAN
3. strace xdvi ends by 
read(3, 0xbffff3e0, 32)                 = -1 EAGAIN (Resource temporarily
select(4, [3], NULL, NULL, NULL

socket(PF_UNIX, SOCK_STREAM, 0)         = 3
Comment 1 Rutger Noot 2001-07-06 08:50:24 EDT
Created attachment 22849 [details]
result of  strace xdvi rubin
Comment 2 Tim Waugh 2001-07-06 08:52:22 EDT
Definitely a kernel problem.  Reassigning.
Comment 3 Tim Waugh 2001-07-06 08:53:24 EDT
(Or, come to think of it, maybe X.)
Comment 4 Rutger Noot 2001-07-06 09:10:48 EDT
This seems to an X problem indeed. 
It happens under XFree-4 (the server I use by default), but it stops 
happening when I pass to XF86_SVGA.
Comment 5 Rutger Noot 2001-07-11 08:22:15 EDT
This is more difficult to reproduce than I thought, it seems that the
sawfish configuration has something to do with it! (I am using sawfish-0.38
from ximian, but the hang still occurs after downgrading to 0.36 from the 
seawolf cd). I'll attach a tarfile with the simpelest reproduction of the 
problem that I could find. To reproduce
1. create a new account
2. throw away all files (including .*)
3. unpack testcase.tar in the home dir
4. open an Xsession (this will just open an xterm and launch sawfish)
5. type "xdvi rubin" into the xterm (rubin.dvi is supplied in the tarball)
Comment 6 Rutger Noot 2001-07-11 08:24:59 EDT
Created attachment 23287 [details]
tarfile of confuguration to reproduce bug
Comment 7 Rutger Noot 2001-07-11 08:37:35 EDT
Sorry, forgot last step to reproduce
6. place mouse in xdvi window and type  6s5s4s3s
Comment 8 Rutger Noot 2001-10-15 03:37:57 EDT
This may very well be a bug of XFree86 4.0.3 (trident chipset).
Starting  xfig hangs the system in similar fashion, see bug 
Comment 9 Mike A. Harris 2001-10-27 18:23:11 EDT
If you add the following to your /etc/XF86Config-4, in the
Screen section:

     Option "NoAccel"

Does the problem still occur?  If the problem goes away, we
can try to narrow it down.

Comment 10 Rutger Noot 2001-10-28 16:10:16 EST
yes, the problem disappears with Option NoAccel.
Comment 11 Mike A. Harris 2001-10-28 23:37:00 EST
Ok, can you please attach a copy of your XFree86 config file, your
log file both as separate text file attachments using the link below.

Next step is to determine what specific XAA acceleration primitives
are failing to work correctly.  To do that, you need to comment out the
freshly added Option Noaccel, and go through each of the individual
XAA primitive disabling directives in the config file.  If you look
at "man XF86Config"  you'll find a bunch of options starting with
XAANoxxxxxxx such as XAANoScreenToScreenCopy.  Use these directives
one at a time, and see which ones stop the problems from occuring.
Once you've determined which ones fix it, we can set it to default that 
particular option to off until the driver can be fixed.  At the same time
you'll be able to enjoy a mostly accelerated setup.
Comment 12 Rutger Noot 2001-10-29 12:34:16 EST
Created attachment 35461 [details]
XFree86 configuration file
Comment 13 Rutger Noot 2001-10-30 04:35:06 EST
Created attachment 35641 [details]
XFree log file
Comment 14 Rutger Noot 2001-10-30 04:40:21 EST
Finally succeeded to attach the log file. 
Please note that (as I tried to attach it in vain yesterday)
the log file does not correspond exactly to the Config file.
The  Option "NoAccel" has been replaced by 

Option "XaaNoScreenToScreenCopy"

That seems to be sufficient to get rid of the problems of both xdvi
and xfig! I'll test it over a longer period to be sure. 

Thanks for your help, please let me know if you want me to do some 
more testing.
Comment 15 Rutger Noot 2002-03-14 07:06:51 EST
You closed bug 41230 and you can also close this one, with resolution  ERRATA
Comment 16 Mike A. Harris 2002-03-14 13:04:08 EST
Ok great, thanks.

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