gnome-terminal 2.8.0 crash if you try to select text while you have a VERY activ task inside like for instance the linux port of cubic player (real-time like ncurses program). 2.8.2 seems stable so far when testing. But 2.8.2 still has the drawing problems when scrolling with shift-up/down, that some random lines blanks out to background-color, and marking the text with the mouse makes it appears again.
How about: o) your `emerge info` o) a backtrace? o) the crash error? Would be most useful, thanks.
this works: FEATURES=nostrip CFLAGS="-g" CXXFLAGS=$CFLAGS USE=debug emerge gnome-terminal this gives crash sometimes, not always: FEATURES=nostrip CFLAGS="-march=athlon -msse -m3dnow -mmmx -fomit-frame-pointer -mfpmath=sse" emerge gnome-terminal I have tested a bunch of options, and I'm unable to trigger this bug when -g is present for instance. Seems like it is very timing depended. Race condition perhaps? #gdb /usr/bin/gnome-terminal <snip> [Switching to Thread 16384 (LWP 22891)] strcmp () at ../sysdeps/i386/i686/strcmp.S:40 40 ../sysdeps/i386/i686/strcmp.S: No such file or directory. in ../sysdeps/i386/i686/strcmp.S Current language: auto; currently asm (gdb) bt #0 strcmp () at ../sysdeps/i386/i686/strcmp.S:40 #1 0x402da6ca in vte_terminal_forkpty () from /usr/lib/libvte.so.4 #2 0x082e0bb8 in ?? () (gdb) info registers eax 0x30 48 ecx 0x82e0bb8 137235384 edx 0x0 0 ebx 0x4036b740 1077327680 esp 0xbffff06c 0xbffff06c ebp 0x817cd88 0x817cd88 esi 0x82e0bb8 137235384 edi 0x1 1 eip 0x40f0f27a 0x40f0f27a eflags 0x210206 2163206 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x0 0 (gdb) disassemble Dump of assembler code for function strcmp: 0x40f0f270 <strcmp+0>: mov 0x4(%esp,1),%ecx 0x40f0f274 <strcmp+4>: mov 0x8(%esp,1),%edx 0x40f0f278 <strcmp+8>: mov (%ecx),%al 0x40f0f27a <strcmp+10>: cmp (%edx),%al 0x40f0f27c <strcmp+12>: jne 0x40f0f287 <strcmp+23> 0x40f0f27e <strcmp+14>: inc %ecx 0x40f0f27f <strcmp+15>: inc %edx 0x40f0f280 <strcmp+16>: test %al,%al 0x40f0f282 <strcmp+18>: jne 0x40f0f278 <strcmp+8> 0x40f0f284 <strcmp+20>: xor %eax,%eax 0x40f0f286 <strcmp+22>: ret 0x40f0f287 <strcmp+23>: mov $0x1,%eax 0x40f0f28c <strcmp+28>: mov $0xffffffff,%ecx 0x40f0f291 <strcmp+33>: cmovb %ecx,%eax 0x40f0f294 <strcmp+36>: ret 0x40f0f295 <strcmp+37>: nop 0x40f0f296 <strcmp+38>: nop 0x40f0f297 <strcmp+39>: nop 0x40f0f298 <strcmp+40>: nop 0x40f0f299 <strcmp+41>: nop 0x40f0f29a <strcmp+42>: nop 0x40f0f29b <strcmp+43>: nop ---Type <return> to continue, or q <return> to quit--- 0x40f0f29c <strcmp+44>: nop 0x40f0f29d <strcmp+45>: nop 0x40f0f29e <strcmp+46>: nop 0x40f0f29f <strcmp+47>: nop End of assembler dump.
not a very useful backtrace with all the CFLAGS crap, what is your 'emerge info' anyway ? Isn't this because of non-sane cflags in the first place ? Recompile the whole tidbit with sane CFLAGS set, stripping off and USE=debug , then get a backtrace. We don't need the disassambler & register stuff, we didn't ask for it, it means nothing.
I'm invalidating it since it seems to be a race condition that is very hard to trigger and rare, and can be anywhere in gnome, orbit, gnome-terminal, glib, glibc.. I don't have time to debug it further since it rarely triggers, and I have problems getting symbols up and running in all the libraries needed.
