Created attachment 124355 [details]
strace xterm

Perhaps there are some font resources set for which it is not
working, e.g., a missing or corrupt font.

The -s option of strace can be set to make the lines long
enough to show the font-name in the trace.

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 ? 

Created attachment 124424 [details]
strace xterm

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.

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:
  http://people.redhat.com/~jvdias/xterm-debug/FC-4

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: 
  /tmp/{Trace-parent.out,Trace-child.out,core.*}

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.

Created attachment 124478 [details]
output of xterm-debug and core file

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:
---
xtermLoadWideFonts:1
SetVTFont(which=0, f_n=<null>, f_b=<null>)
set myfonts.f_n from menu_font_names[0][fNorm]
-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
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
-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
xtermLoadFont #0 bold   <null>
xtermLoadFont #0 wide   <null>
xtermLoadFont #0 w/bold <null>
BELL 0
---

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:
   xorg-x11-6.8.2-37.FC4.49.2
   glibc-2.3.5-10.3
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:
  http://people.redhat.com/~jvdias/xterm-debug/FC-4/

Thanks!

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.

It appears to be sufficient to add a check if "term" is realized
in Bell() - I added that to my ongoing changes toward #209.

I am running exactly these two versions:

 xorg-x11-6.8.2-37.FC4.49.2
 glibc-2.3.5-10.3

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
/usr/lib/X11/appdefaults/Xterm.

The architecture of my machine is x86_64 (SunFire V40Z with 4 Dual Core
AMD/Opteron).

Regards

Joachim Backes

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.

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.

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.

After testing: seems to be fixed.