Environment: Newly installed system, built on 16 Feb 03. Installed GNOME 2.2 (by doing `emerge gnome`). Other software previously present: `emerge X evolution gimp` etc
GNOME 2.2 runs well on Laptop's LCD screen. Specifically, gnome-terminal pops up with no problem. However, I normally access this machine remotely via an XDMCP session from my desktop. I tried running this; was able to log in. Nautalis runs fine, but when I try to run gnome-terminal it IMMEDIATELY crashes.
Steps to Reproduce:
1. emerge gnome [version 2.2]
2. have gdm as default display manager
3. login locally; verify gnome-terminal works. Yes.
4. login remotely using XDMCP
5. try gnome-terminal. Fails.
Terminal crashes shortly after window manager draws window decorations.
Can be reproduced by logging in both from another Linux machine (using `XHost :2 -server <IPaddress>`) and from a Windows based PC X server (Xwin32)
Actual error message follows:
The program 'gnome-terminal' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
(Details: serial 192 error_code 11 request_code 53 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Given me a terminal!
This is very serious. Yes, I could use a different terminal program, but gnome-terminal really shouldn't be crashing when used over XDMCP like this, and it is what pops up when you ask GNOME for a terminal. I kinda need shell prompts...
Should I report this upstream?
Portage 2.0.46-r12 (default-x86-1.4, gcc-3.2.1, glibc-2.3.1-r2)
System uname: 2.4.20-acpi-r9 i686 Mobile Intel(R) Pentium(R) III CPU - M 933MHz
CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/share/config"
USE="x86 oss 3dnow apm arts crypt cups encode gif jpeg mpeg ncurses nls png quicktime spell xml2 xmms xv zlib gdbm berkdb slang readline svga guile X sdl tcpd pam ssl python esd imlib oggvorbis opengl gnome -alsa -avi -gpm -kde -libg++ maildir -mikmod -motif -qt -qtmt dga doc dvd gd gphoto2 gtk imap java ldap libwww mmx mozilla pda pdflib perl samba sse tcltk tiff truetype usb bonobo evo gtkhtml"
CFLAGS="-march=pentium3 -O2 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium3 -O2 -pipe -fomit-frame-pointer"
rare cases are _NOT_ blockers to Gentoo as a whole. Besides that it looks that you may have hit a real gnome-terminal bug, check if the gnome bugzilla has anything on it.
Entered upstream as GNOME bug 106308.
Havoc Pennington closed the GNOME bug as RESOLVED/NOTGNOME with this:
"This is an Xft bug. I'm not sure if newer versions have it fixed
but I think it's fixed in Xft CVS"
If that is the case, then what should I do to go about a) installing said version of XFT on my system and b) testing so that c) Gentoo Linux can be better :) ? AfC
hmm yeah, you could test it, but i can't guarantee it's going in anytime soon, it is after all CVS. I could talk about putting in a newer cvs snapshot with Azarah if it works for you.
i recently merged gnome2(fresh system even) and i dont have this problem at all
i am using xfree 4.3 and xft and whatever other depends that 4.3 wanted that was masked
The same problem.
Using X-Win32 5.3
but before error message reported by Andrew I always get the following string:
Xlib: extension "RENDER" missing on display "mymachine.mydomain:0.0".
Using Xwin32 I get the same "RENDER extension missing" error; I, however, get that from numerous applications, and having disucssed it with the StarNet engineers and also having searched through mailing lists about xft, etc, [the lack of the RENDER extension] is not the problem.
I cut and paste the error output when I tried using a Debian system as the remote display (and where the RENDER error didn't ocur) just because the root "gnome-terminal doesn't work over XDMCP" problem occurs on more than just Xwin32 and I didn't want people to get focused on to the RENDER warning.
Good to see I'm not the only one, Andy. Cheers.
current xfree-4.3-r2 and up have latest (well almost) Xft2, any improvements ?
beep ? please see #7
Hey foser, sorry - bugs.gentoo.org was down last I tried to update this.
I emerged/updated xfree to the latest version, and no joy, I'm afraid. Still the same problem - can't run gnome-terminal.
Would you like to try remoting a display off my machine? I might be able to arrange that.
Am I supposed to remove the xft-2.0.1-r2? I saw that "blocking" dependency when I went through, but somehow it wasn't a problem to emerge updating xfree; but am I supposed to blow xft itself away on the understanding xfree-4.3-r2 has its own?
[This is all based on Havoc sending us after Xft; it could of course be something else]
yes you were supposed to remove it. Right now you are probably still using the system xft. Removing it might remove some common files (thats the reason it was a blocker (!)) and you probably have to rebuild xfree as well afterwards.
We don't block things for nothing.
I manually unmerged x11-libs/xft, then reconnected to my remote X server. gnome-terminal runs now. (YEAY!)
I have not rebuilt Xfree yet; if it's not necessary I wont. I'll let you know if any unsteadiness shows up.
Still not sure how I managed to emerge xfree without being stopped by the block in xft. <shrug>
well you probably need to rebuild it because currently xft apps most likely won't build. But i'm glad to hear it takes care of this bug.
Andy of #5 , is the problem still there for you with recent xft/fontconfig/xfree ?
Sorry, but I changed my mobo & CPU (AMD K6-II -> Celeron-300)yesterday and have to recompile the whole system (damn! I compiled only for K6-II!)
So with 300 Mhz Celeron it will take some time...
(and there's no space left on my 2,5 Gb HDD, I have to deal with this problem too :)
I'll let you know when as soon as my system will come to life again
waiting for a bit of user interaction since we can't test this.