Description of problem: After a fresh install, w3m works fine. After a while, w3m always segfaults. prelink seems to be the culprit. Version-Release number of selected component (if applicable): prelink-0.3.0-20 w3m-0.4.1-9 How reproducible: always Steps to Reproduce: 1. rpm -e w3m 2. rpm -ivh w3m-0.4.1-9.i386.rpm 3. w3m -version 4. prelink /usr/bin/w3m-en 5. w3m -version Actual results: 3. w3m version w3m/0.4.1-m17n-20030308, options lang=en,m17n,image, color,ansi-color,mouse,gpm,menu,cookie,ssl,ssl-verify, external-uri-loader,w3mmailer,nntp,gopher,ipv6,alarm,mark 5. Segmentation fault Expected results: 5. like 3. under "actual results" Additional info: This also happens with self-compiled versions of w3m, also with other optimizations.
w3m (well, the GC it uses) is buggy. It makes assumptions about __libc_stack_end which it certainly should not do. --- w3m-0.4.1/gc/os_dep.c.jj 2003-05-09 04:43:47.000000000 +0200 +++ w3m-0.4.1/gc/os_dep.c 2004-02-09 18:33:10.000000000 +0100 @@ -897,7 +897,7 @@ ptr_t GC_get_stack_base() size_t i, buf_offset = 0; /* First try the easy way. This should work for glibc 2.2 */ - if (0 != &__libc_stack_end) { + if (0 != &__libc_stack_end && __libc_stack_end != 0) { # ifdef IA64 /* Some versions of glibc set the address 16 bytes too */ /* low while the initialization code is running. */
Fixed in 0.4.1-10, which will be available soon. Thanks!
*** Bug 115702 has been marked as a duplicate of this bug. ***
I can confirm: 0.4.1-10 works for me. Thanks!
*** Bug 117754 has been marked as a duplicate of this bug. ***