Bug 180450

Summary: xterm dies with output on X-terminals
Product: [Fedora] Fedora Reporter: Joachim Backes <joachim.backes>
Component: xtermAssignee: Miroslav Lichvar <mlichvar>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: dickey
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-17 15:51:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
strace xterm
strace xterm
output of xterm-debug and core file none

Description Joachim Backes 2006-02-08 06:59:06 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051202 Fedora/1.5-0.fc4 Firefox/1.5

Description of problem:
Starting xterm (no option given) with output on X-terminal like IGEL or NCD dies with:

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Resource id in failed request:  0x0
  Serial number of failed request:  95
  Current serial number in output stream:  96

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.login into some x desktop starting from x-terminal

Actual Results:  xterm crashes

Expected Results:  xterm runs

Additional info:

No crash if starting xterm with some font,

xterm -fn fixed

for example

Comment 1 Joachim Backes 2006-02-08 07:00:52 UTC
Created attachment 124355 [details]
strace xterm

Comment 2 Thomas E. Dickey 2006-02-08 16:29:50 UTC
Perhaps there are some font resources set for which it is not
working, e.g., a missing or corrupt font.

Comment 3 Thomas E. Dickey 2006-02-08 16:33:21 UTC
The -s option of strace can be set to make the lines long
enough to show the font-name in the trace.

Comment 4 Jason Vas Dias 2006-02-08 17:09:42 UTC
Yes, as suggested in previous comment, please use this command to obtain an
strace showing the font xterm is actually trying to load:
  # strace -s1024 -oxterm.strace.log xterm

By default, xterm will try to use the "fixed" font; since "xterm -fn fixed" 
works OK for you, this suggests that there is some setting of the *font or 
*VT100*font Xresource, which sets xterm's default font if no -fn option is
supplied. What is the output of
  # xrdb -query -all | grep 'font:' 

If you do not set this resource explicitly, try setting it with :
  # echo '*VT100*font: fixed' | xrdb -merge
Then does the 'xterm' command, without any arguments, work OK ? 

Comment 5 Joachim Backes 2006-02-09 06:08:36 UTC
Created attachment 124424 [details]
strace xterm

Comment 6 Joachim Backes 2006-02-09 06:09:24 UTC
xrdb -query -all | grep 'font:' 

*SimpleMenu*font:       *helvetica*r*normal*12*
XDvi*font:      *helvetica*r*normal*12*
emacs*font:     fixed


echo '*VT100*font: fixed' | xrdb -merge
Then does the 'xterm' command, without any arguments, work OK ?
Answer: No, it's not running OK.

I have attached  xterm.strace.log.gz following your advice.

What I not understand: I'm logging in into the FC4 box via gdm display mamager
using a failsave session, and the initial xterm !!!!runs!!!! without any font
statement, but no explicitly called xterms during the session.

Comment 7 Jason Vas Dias 2006-02-09 18:51:42 UTC
Thanks for the strace log. Something very strange is going on here -
it seems that the error always occurs when XChangeProperty is called
with a Window parameter of 0 - an invalid window ID.

To determine exactly where / why this is happening, I've made an 
'xterm-debug' RPM, which you can download from:

Please download and install the xterm-debug-207-2.DBG.i386.rpm from
the location above - if you're not running on an i386 platform, then
download the src.rpm, and rebuild with:
  # rpmbuild --rebuild xterm-debug-207-2.DBG.src.rpm
and install the resulting /usr/src/redhat/RPMS/${ARCH}/xterm-debug-207-2*.rpm

This will install the /usr/bin/xterm-debug program, ONLY. It should not affect
your existing "xterm" rpm installation in any way.

Then run xterm-debug, with core file generation enabled:
  # ulimit -c unlimited; cd /tmp; rm -f core.*; xterm-debug

The xterm-debug consists of xterm with full GDB debugging and xterm tracing 
enabled, and modified to generate a core dump on the occurrence of an X error.
xterm-debug will have created these files after it exits with an X error: 

Please tar them up and compress: 
  # tar -cpf - /tmp/{Trace-parent.out,Trace-child.out,core.*} |
    gzip >   /tmp/xterm-debug.tar.gz
and send the /tmp/xterm-debug.tar.gz file to me or append it to this bug report
- thank you.

Comment 8 Joachim Backes 2006-02-10 06:15:21 UTC
Created attachment 124478 [details]
output of xterm-debug and core file

Comment 9 Jason Vas Dias 2006-02-10 18:11:24 UTC
Many thanks for the debug output. 

I believe the problem is revealed in the "Trace-parent.out" log file.

During the initial load of the fonts, your X-terminal wants to emit a BELL -
this comes at an unfortunate time for xterm, before the window is fully 
initialized, and the Window ID parameter of XChangeProperty is 0 . 
The Trace-parent.out log ends:
SetVTFont(which=0, f_n=<null>, f_b=<null>)
set myfonts.f_n from menu_font_names[0][fNorm]
set myfonts.f_b from menu_font_names[0][fBold] <null>
set myfonts.f_w from menu_font_names[0][fWide] <null>
set myfonts.f_wb from menu_font_names[0][fWBold] <null>
xtermLoadFont #0 normal
xtermLoadFont #0 bold   <null>
xtermLoadFont #0 wide   <null>
xtermLoadFont #0 w/bold <null>

Then the xerror occurs, because  XtWindow(vt) is then 0 . At least, I think
that is what is happening. Unfortunately, the core file shows nothing, probably
because of a version mismatch .  

Please confirm: you are running the latest FC-4 updates ? ie. at least:
which versions of xorg-x11 and glibc are you running ? What architecture ? 
ie. is it plain i386/i686, or x86_64 ?

I've made an xterm-debug-207-3.DBG version, which will avoid calling
XChangeProperty in Bell() if the window ID is 0 .  Please try out this 
version and see if it fixes the problem:


Comment 10 Thomas E. Dickey 2006-02-10 19:03:13 UTC
That sounds like the call to SetVTFont() from charproc.c
is running into a problem (cannot load the font).  That's
during the widget realize - and offhand I'd have thought
the window was real at that point (something that's easily
verified anyway).  If there were a walkback it would be
easier to diagnose.  In any case, the program dies because
it cannot load the requested font.

Comment 11 Thomas E. Dickey 2006-02-12 00:25:02 UTC
It appears to be sufficient to add a check if "term" is realized
in Bell() - I added that to my ongoing changes toward #209.

Comment 12 Joachim Backes 2006-02-13 06:15:42 UTC
I am running exactly these two versions:


The xterm-debug you sent to me fixes my problems and was running correctley and
did not break without entering some font in xterm call or in

The architecture of my machine is x86_64 (SunFire V40Z with 4 Dual Core


Joachim Backes

Comment 13 Jason Vas Dias 2006-02-13 16:58:51 UTC
This bug should now be fixed with xterm-208-1.FC4, released to FC-4
updates/testing today . 
Please try out this version and let me know of any issues - thanks.

Comment 14 Fedora Update System 2006-02-13 17:02:32 UTC
From User-Agent: XML-RPC

xterm-208-1.FC4 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Comment 15 Fedora Update System 2006-02-21 16:20:22 UTC
From User-Agent: XML-RPC

xterm-208-1.FC4 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Comment 16 Joachim Backes 2006-02-22 05:40:11 UTC
After testing: seems to be fixed.