Using x86_64 test1 release.
when using vim (/usr/bin/vim), and creating a file:
[root@dw1.dw root]# vim blah
..typing some text, then saving with :wq, presents the following:
Vim: Caught deadly signal ILL Vim: preserving files...
Vim: Finished. Illegal instruction
../bin/vi does *not* have this problem,
Any ideas? any output I can capture to help narrow down the issue?
Ken Snider wrote:
Using x86_64 test1 release.
when using vim (/usr/bin/vim), and creating a file:
[root@dw1.dw root]# vim blah
..typing some text, then saving with :wq, presents the following:
Vim: Caught deadly signal ILL Vim: preserving files...
Vim: Finished. Illegal instruction
../bin/vi does *not* have this problem,
Any ideas? any output I can capture to help narrow down the issue?
run it under the debugger gdb,
gdb vim run blah
after it crashes, capture a stack trace with the 'bt' command
Nathan Bryant wrote:
run it under the debugger gdb,
gdb vim run blah
after it crashes, capture a stack trace with the 'bt' command
To reproduce:
gdb vim run blah (enter some text, :wq out)
Result:
Program received signal SIGILL, Illegal instruction. 0x0000003f53301c30 in ?? () from /lib64/tls/libm.so.6 (gdb) bt #0 0x0000003f53301c30 in ?? () from /lib64/tls/libm.so.6 #1 0x0000003f53702f28 in acl_get_file () from /lib64/libacl.so.1 #2 0x000000000044999a in ?? () #3 0x0000000000426010 in ?? () #4 0x0000000000437f13 in ?? () #5 0x0000000000433284 in ?? () #6 0x0000000000431a58 in ?? () #7 0x000000000048338e in ?? () #8 0x000000000047eb24 in ?? () #9 0x000000000045ac98 in ?? () #10 0x0000000000459ce9 in ?? () #11 0x0000003f5301d181 in __libc_start_main () from /lib64/tls/libc.so.6 #12 0x000000000040362a in ?? ()
I tried installing glibc-debug to see if I could get something more descriptive, but no luck.
Nathan Bryant wrote:
Ken Snider wrote:
[mostly-symbolless backtrace snipped]
I tried installing glibc-debug to see if I could get something more descriptive, but no luck.
Hmm... try installing vim-debuginfo.
Nope, no luck, no debuginfo package for it.
The editor actually receives *two* SIGILL's.. one after the other. Here's the (in)complete backtrace for both signals:
"test" Program received signal SIGILL, Illegal instruction. 0x0000003f53301c30 in ?? () from /lib64/tls/libm.so.6 (gdb) bt #0 0x0000003f53301c30 in ?? () from /lib64/tls/libm.so.6 #1 0x0000003f53702f28 in acl_get_file () from /lib64/libacl.so.1 #2 0x000000000044999a in ?? () #3 0x0000000000426010 in ?? () #4 0x0000000000437f13 in ?? () #5 0x0000000000433284 in ?? () #6 0x0000000000431a58 in ?? () #7 0x000000000048338e in ?? () #8 0x000000000047eb24 in ?? () #9 0x000000000045ac98 in ?? () #10 0x0000000000459ce9 in ?? () #11 0x0000003f5301d181 in __libc_start_main () from /lib64/tls/libc.so.6 #12 0x000000000040362a in ?? () (gdb) c Continuing. Vim: Caught deadly signal ILL
Vim: Finished.
Program received signal SIGILL, Illegal instruction. 0x0000003f5302f3b9 in kill () from /lib64/tls/libc.so.6 (gdb) bt #0 0x0000003f5302f3b9 in kill () from /lib64/tls/libc.so.6 #1 0x00000000004998dc in ?? () #2 0x0000000000498a70 in ?? () #3 <signal handler called> #4 0x0000003f53301c30 in ?? () from /lib64/tls/libm.so.6 #5 0x0000003f53702f28 in acl_get_file () from /lib64/libacl.so.1 #6 0x000000000044999a in ?? () #7 0x0000000000426010 in ?? () #8 0x0000000000437f13 in ?? () #9 0x0000000000433284 in ?? () #10 0x0000000000431a58 in ?? () #11 0x000000000048338e in ?? () #12 0x000000000047eb24 in ?? () #13 0x000000000045ac98 in ?? () #14 0x0000000000459ce9 in ?? () #15 0x0000003f5301d181 in __libc_start_main () from /lib64/tls/libc.so.6 #16 0x000000000040362a in ?? ()
I don't actually think that's any more informative, but hey. :)
Ken Snider wrote:
Nope, no luck, no debuginfo package for it.
They are in their own repository:
http://download.fedora.redhat.com/pub/fedora/linux/core/test/0.96/x86_64/deb...
Nathan Bryant wrote:
They are in their own repository:
http://download.fedora.redhat.com/pub/fedora/linux/core/test/0.96/x86_64/deb...
I've added that repository to my sources file. :)
Unfortunately that made no difference in the backtrace.
The RPM for vim-debuginfo is only 16K, and further, an rpm -ql of that RPM results in 0 files listed.. so I'm wondering what exactly the package does if it contains no files? is there an argument I should pass to gdb?
Ken Snider wrote:
The RPM for vim-debuginfo is only 16K, and further, an rpm -ql of that RPM results in 0 files listed.. so I'm wondering what exactly the package does if it contains no files? is there an argument I should pass to gdb?
Looks like vim wasn't really built with support for debuginfo and you'd have to rebuild the SRPM with the proper compiler options. Not much fun...
..thought I'd point out that reverting to kernel 2135 *eliminated* the problem I was seeing with vim-enhanced (writing to disk resulted in SIGILL's). I'll open a bugzilla ticket against 2163 on this issue I guess.
The only outstanding issue I've seen now is that if I set LD_ASSUME_KERNEL=2.2.5 I get the following odd errors (and this is with any binary, not just dmesg in the example below:
[ksnider@dw1.dw ksnider]$ ldd `which uname` libc.so.6 => /lib64/tls/libc.so.6 (0x0000003f53000000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000003f52e00000) [ksnider@dw1.dw ksnider]$ uname -a Linux dw1.dw 2.4.22-1.2135.nptlsmp #1 SMP Mon Dec 15 15:45:38 EST 2003 x86_64 x86_64 x86_64 GNU/Linux [ksnider@dw1.dw ksnider]$ export LD_ASSUME_KERNEL=2.2.5 [ksnider@dw1.dw ksnider]$ uname -a uname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory [ksnider@dw1.dw ksnider]$ unset LD_ASSUME_KERNEL [ksnider@dw1.dw ksnider]$ uname -a Linux dw1.dw 2.4.22-1.2135.nptlsmp #1 SMP Mon Dec 15 15:45:38 EST 2003 x86_64 x86_64 x86_64 GNU/Linux
Very odd, looks like something is munging the LD_LIBRARY_PATH perhaps with NPTL disabled?
-
Ken Snider -
Nathan Bryant