Hide Forgot
Description of problem: After upgrading my xterm rpm, "xterm -cm now" crashes Version-Release number of selected component (if applicable): xterm-208-1.FC4 How reproducible: always Steps to Reproduce: 1. install xterm-208-1.FC4 2. xterm -cm Actual results: xterm crashes with the following output: xterm: warning, error event received: X Error of failed request: BadGC (invalid GC parameter) Major opcode of failed request: 65 (X_PolyLine) Resource id in failed request: 0x9feb650 Serial number of failed request: 212 Current serial number in output stream: 226 Expected results: xterm runs with ANSI color sequences disabled as per the man page. Additional info: I've tried this on two seperate fc4 boxes with the same results. downgrading to 207-2.FC4 fixes problem (problem introduced in newest version)
Very strange - this is NOT happening at all on the two FC-4 machines I've tested - 'xterm -cm' works fine. You are running the latest xorg-x11-6.8.2-37.FC4.49.2 release with glibc-2.3.5-10.3 ? GNOME or KDE window manager ? What architecture - i386 / x86_64 ? Please could you download and run this debugging version of xterm : http://people.redhat.com/~jvdias/xterm-debug/ Download and install the xterm-debug-208-1.DBG.i386.rpm if you are running on an ia32e platform, or download the xterm-debug-208-1.DBG.src.rpm and run # rpmbuild --rebuild xterm-debug-208-1.DBG.src.rpm and install the resulting /usr/src/redhat/RPMS/${ARCH}/xterm-debug*.rpm. This provides ONLY the /usr/bin/xterm-debug executable, and does not conflict with your existing xterm installation - it will tell us exactly where / why the error is occurring. Running # ulimit -c unlimited; xterm-debug -cm will create the Trace-{parent,child}.out files in the current directory, and, if any X error occurs, will create a core.$pid coredump file. Please tar up these files: # tar -cpf - Trace-{parent,child}.out core.* | gzip > xterm-debug.tar.gz and send me (jvdias) the resulting xterm-debug.tar.gz file or append it to this bug report - thank you!
I can reproduce this (at least once). I'll take a look now and give more information if it stays.
It's time-sensitive, but might be a variation of 178302. In this case, the if-statement further down in set_cursor_gcs() } else #endif if (cc != fg && cc != bg) { /* we have a colored cursor */ doesn't match the previous if-statement, which happens to check if the window's been created. If I change that to } else #endif if (VWindow(screen) != 0 && (cc != bg)) { /* we have a colored cursor */ then the problem appears to go away.
Aha! Thanks, Thomas - patch applied in xterm-208-2.FC4 and xterm-209-2(FC5) . Please try out the xterm-208-2.FC4 RPMs (available shortly from FC-4 Updates/Testing) and let me know if the problem is fixed - thanks!
From User-Agent: XML-RPC xterm-208-2.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.
just tested 208-2.FC4, problem fixed. thanks all -alan
thanks for the verification - I'll have that fix in #210