In a KDE Konsole terminal window, if you type "clear" at the command line prompt to clear the screen, a core file is created and the screen is not cleared. (Fortunately, Konsole keeps running.) This bug appeared in 6.2; it was not present in 6.1 or 6.0.
I can't reproduce this. Was it an installation or an upgrade, and if an installation which installation path did you choose?
I have the same issue. I installed with a 6.2 KDE workstation install. I didn't format the /usr partition, however. I see the bug both in the kconsole and in any xterms that I spawn.
I don't have this problem... clear works just fine. I upgraded my RH 6.0 directly to RH 6.2.
Can't reproduce it... Please send me the output of "strace clear".
I get a similar behavior in aterm's. Here is the output of strace: 36 ## charon> strace clear execve("/usr/bin/clear", ["clear"], [/* 23 vars */]) = 0 brk(0) = 0x80497c4 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=41543, ...}) = 0 old_mmap(NULL, 41543, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000 close(3) = 0 open("/usr/local/lib/libncurses.so.4", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=269580, ...}) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \336\0"..., 4096) = 4096 old_mmap(NULL, 249100, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40020000 mprotect(0x40051000, 48396, PROT_NONE) = 0 old_mmap(0x40051000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x30000) = 0x40051000 old_mmap(0x4005a000, 11532, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4005a000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=4101324, ...}) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\210\212"..., 4096) = 4096 old_mmap(NULL, 1001564, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4005d000 mprotect(0x4014a000, 30812, PROT_NONE) = 0 old_mmap(0x4014a000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xec000) = 0x4014a000 old_mmap(0x4014e000, 14428, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4014e000 close(3) = 0 mprotect(0x4005d000, 970752, PROT_READ|PROT_WRITE) = 0 mprotect(0x4005d000, 970752, PROT_READ|PROT_EXEC) = 0 munmap(0x40015000, 41543) = 0 personality(PER_LINUX) = 0 getpid() = 2734 brk(0) = 0x80497c4 brk(0x8049f54) = 0x8049f54 brk(0x804a000) = 0x804a000 access("/root/.terminfo/x/xterm", R_OK) = -1 ENOENT (No such file or directory) access("/usr/local/share/terminfo/x/xterm", R_OK) = 0 open("/usr/local/share/terminfo/x/xterm", O_RDONLY) = 3 read(3, "\32\0010\0\35\0\17\0i\1\307\3", 12) = 12 brk(0x804b000) = 0x804b000 read(3, "xterm|xterm terminal emulator (X"..., 48) = 48 read(3, "\0\1\0\0\1\0\0\0\1\0\0\0\0\1\1\0\0\0\0\0\0\0\1\0\0\0\0"..., 29) = 29 read(3, "\0", 1) = 1 read(3, "P\0\10\0\30\0\377\377\377\377\377\377\377\377\377\377\377"..., 30) = 30 read(3, "\0\0\4\0\6\0\10\0\31\0\36\0&\0*\0.\0\377\3779\0J\0L\0P"..., 722) = 722 read(3, "\33[Z\0\7\0\r\0\33[%i%p1%d;%p2%dr\0\33[3g\0\33["..., 967) = 967 close(3) = 0 ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, TIOCGWINSZ, {ws_row=65, ws_col=85, ws_xpixel=0, ws_ypixel=0}) = 0 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++
Still can't reproduce it anywhere. Please attach the core dump file.
We've tried this on more than 200 machines now and can't reproduce it anywhere. If this still happens for you, make sure that - you are not using a broken termcap file. Re-Install the Red Hat Linux termcap and ncurses RPMs, and delete any .termcap or .terminfo files/directories you have in your home directory. - make sure you're using the Red Hat Linux packages. You can use rpm -V to verify their integrity.
Commit pushed to master at https://github.com/openshift/origin https://github.com/openshift/origin/commit/8c99bd5f5bdb8e4c413996518803529baf15417c Adding warning about port 8443 potentially being blocked by firewall rules on oc cluster up Fixes issue #10807