I'm getting segfaults with w3m and vim when running them in the Linux text console. As I'm speculating that the two crashes might be interrelated, I'm going to describe both in the same e-mail.
I'm running on recent FC devel packages: kernel-2.6.5-1.326 gpm-1.20.1-46 w3m-0.5-2 vim-common-6.2.457-1 vim-enhanced-6.2.457-1
In case it matters, here's my /etc/sysconfig/mouse: FULLNAME="Generic - Wheel Mouse (USB)" MOUSETYPE="imps2" XEMU3="yes" XMOUSETYPE="IMPS/2" DEVICE=/dev/input/mice
======================================================================== ISSUE #1:
When running in the Linux text console, w3m crashes immediately after rendering any webpage. $ echo $TERM linux
$ ldd /usr/bin/w3m [...] libgpm.so.1 => /usr/lib/libgpm.so.1 (0x00521000) libtermcap.so.2 => /lib/libtermcap.so.2 (0x0089f000) libc.so.6 => /lib/tls/libc.so.6 (0x0054f000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00537000)
$ rm -rf ~/.w3m
$ /usr/bin/w3m http://www.google.com/ Program received signal SIGSEGV, Segmentation fault. 0x00524af0 in Gpm_Wgetch (win=0x0) at lib/libcurses.c:80 80 return GET(win); (gdb) bt #0 0x00524af0 in Gpm_Wgetch (win=0x0) at lib/libcurses.c:80 #1 0x08091a2c in do_getch () at terms.c:1852 #2 0x0804c797 in main (argc=2, argv=0xfeee8254, envp=0xfeee8260) at main.c:1094 #3 [...]
For your information, GET(0) is just a macro in gpm's libcurses.c that evaluates to getch(). Why should something as simple as getch() segfault?
It works fine when w3m is running under gnome-terminal with TERM=xterm, but crashes as described above if I run it in gnome-terminal and force TERM=linux.
If the gpm daemon is not running, the /dev/gpmctl socket does not exist, and the screen is littered with the following diagnostic messages. But w3m crashes in exactly the same way whether or not gpm is running. *** info [lib/liblow.c(326)]: /dev/gpmctl: No such file or directory *** err [lib/liblow.c(333)]: /dev/gpmctl: No such file or directory *** err [lib/liblow.c(377)]: Oh, oh, it's an error! possibly I die!
It would be nice to get this resolved, since the whole point of w3m is to quickly Google some stuff without firing up the X server =)
======================================================================== ISSUE #2:
Here's a crash in vim that is also somehow mouse related.
$ echo $TERM linux
$ ldd /usr/bin/vim [...] libgpm.so.1 => /usr/lib/libgpm.so.1 (0x00521000) [...]
$ /usr/bin/vim
Then, if you don't already have such a command in your ~/.vimrc, type :set mouse=n
and then type any colon or slash command, such as : or :w or :q
and watch vim explode-- Vim: Caught deadly signal SEGV
Vim: Finished. Segmentation fault
It's certainly challenging trying to use vim without ever hitting the colon or slash keys. Before I figured out the workaround of removing "set mouse" from my .vimrc, I kept losing my work due to vi twitches like :w =)
========================================================================
Any ideas?
Derek
Hi,
On Sun, 18 Apr 2004 05:41:37 -0700 (PDT), "DP" == Derek Poon fedora@derekandkaren.com wrote:
DP> I'm getting segfaults with w3m and vim when running them in the Linux text DP> console. As I'm speculating that the two crashes might be interrelated, DP> I'm going to describe both in the same e-mail.
I saw the same problem too. See also http:/bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120240
it was already filed, but not getting the fix yet.
Regards, -- Akira TAGOH
Thanks, Akira.
I have figured out the root cause of the w3m crash -- it's because w3m isn't linked with libncurses, where the wgetch() function is defined. The linker doesn't complain because gpm has declared wgetch to be a weak symbol. I've noted that information in bug 120240, and further discussion on this topic can be conducted through Bugzilla.
That means that the vim crash I mentioned earlier is due to a different cause.
Derek
On Mon, 19 Apr 2004, Akira TAGOH wrote:
On Sun, 18 Apr 2004 05:41:37 -0700 (PDT), "DP" == Derek Poon fedora@derekandkaren.com wrote:
DP> I'm getting segfaults with w3m and vim when running them in the Linux text DP> console. As I'm speculating that the two crashes might be interrelated, DP> I'm going to describe both in the same e-mail.
I saw the same problem too. See also http:/bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120240
it was already filed, but not getting the fix yet.