=== Install newest elinks === # emerge elinks ... [MAKE all] src/scripting/ruby make[3]: Entering directory `/var/tmp/portage/elinks-0.11.0/work/elinks-0.11.0/src/scripting/ruby' [CC] src/scripting/ruby/core.o [CC] src/scripting/ruby/hooks.o [CC] src/scripting/ruby/ruby.o [LD] src/scripting/ruby/lib.o make[3]: Leaving directory `/var/tmp/portage/elinks-0.11.0/work/elinks-0.11.0/src/scripting/ruby' ... === No error messages there! === # elinks === Enter a URL and sit back === Links-ruby: failed to allocate memory (NoMemoryError) [------] ELinks crashed. That shouldn't happen. Please report this incident to the developers. If you would like to help to debug the problem you just uncovered, please keep the core you just got and send the developers the output of 'bt' command entered inside of gdb (which you run as: gdb elinks core). Thanks a lot for your cooperation! ELinks 0.11.0 (built on Feb 2 2006 04:58:08) Features: Debug, IPv6, gzip, bzip2, Periodic Saving, Timer, Cascading Style Sheets, Protocol (BitTorrent, File, Finger, FTP, Gopher, HTTP, NNTP, SMB, URI rewrite, User protocols), SSL (OpenSSL), MIME (Option system, Mailcap, Mimetypes files), LED indicators, Bookmarks, Cookies, Form History, Global History, Scripting (Lua, Guile, Perl, Ruby), Goto URL History, Search History [0x7] Aborted === Hmmmmf. :-( === # gdb elinks (gdb) run === Enter a URL and sit back === E Links-ruby: failed to allocate memory (NoMemoryError) [------] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 28732)] 0x406f20e8 in rb_throw () from /usr/lib/libruby18.so.1.8 (gdb) backtrace #0 0x406f20e8 in rb_throw () from /usr/lib/libruby18.so.1.8 #1 0x406e2120 in rb_exc_raise () from /usr/lib/libruby18.so.1.8 #2 0x40707cd8 in rb_memerror () from /usr/lib/libruby18.so.1.8 #3 0x40707e18 in ruby_xmalloc () from /usr/lib/libruby18.so.1.8 #4 0x4076aafc in rb_str_new () from /usr/lib/libruby18.so.1.8 #5 0x0003eaa0 in init_guile () #6 0x000f4dc0 in done_event () #7 0x000f46e4 in trigger_event () #8 0x0007fd50 in doc_loading_callback () #9 0x000f5afc in set_connection_state () #10 0x000f80b8 in is_entry_used () #11 0x000f5d10 in add_keepalive_connection () #12 0x00061424 in subst_user_agent () #13 0x000799cc in kill_buffer_data () #14 0x00090284 in select_loop () #15 0x0005a160 in main () (gdb) quit # emerge info Gentoo Base System version 1.6.14 Portage 2.1_pre4-r1 (default-linux/hppa/2005.0, gcc-3.3.6, glibc-2.3.4.20040808-r1, 2.6.15.1-pa4-JeR parisc) ================================================================= System uname: 2.6.15.1-pa4-JeR parisc PA7300LC (PCX-L2) ccache version 2.4 [disabled] dev-lang/python: 2.2.3-r6, 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="hppa" AUTOCLEAN="yes" CBUILD="hppa1.1-unknown-linux-gnu" CFLAGS="-O3 -pipe -mschedule=7100LC -march=1.1" CHOST="hppa1.1-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/ssh /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe -mschedule=7100LC -march=1.1" DISTDIR="/keeps/gentoo/portage/distfiles" FEATURES="autoconfig buildpkg distlocks fixpackages notitles sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.easynet.nl/mirror/gentoo/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo ftp://mirror.scarlet-internet.nl/pub/gentoo ftp://mirror.nutsmaas.nl/gentoo/" LC_ALL="en_US.UTF-8" MAKEOPTS="-j2" PKGDIR="/keeps/gentoo/packages-hpvis" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/keeps/gentoo/portage" PORTDIR_OVERLAY="/keeps/gentoo/local" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="hppa X alsa apache2 bash-completion berkdb bitmap-fonts bittorrent bzip2 c++ cairo caps cdb cjk crypt cups curl elf esd exif expat fame fbcon flac foomaticdb fortran gd gdbm gif gimpprint gnutls gpm gtk gtk2 idn imagemagick imlib ipv6 javascript jpeg lcms libwww lua mad mhash motif ncurses nls offensive ogg oss pam pdflib perl pic png python qt readline recode ruby samba sdl slp snmp spell sqlite ssl svg tcpd threads tiff truetype truetype-fonts type1-fonts unicode usb userlocales v4l vorbis xml2 yaz zlib elibc_glibc kernel_linux userland_GNU video_cards_stifb video_cards_fbdev" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LDFLAGS, LINGUAS
Sorry for the bug spam.
From dmesg: [96305.780000] do_page_fault() pid=28732 command='elinks' type=15 address=0x00000130 [96305.780000] [96305.780000] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [96305.780000] PSW: 00000000000001001111111100001011 Not tainted [96305.780000] r00-03 00000000 407b6778 406f20c3 407c77fc [96305.780000] r04-07 407b4778 407c9e5c 407b4778 407b9f78 [96305.780000] r08-11 00162a88 0011b800 00000006 407b4778 [96305.780000] r12-15 407b4778 dadababa 0017f288 407c77fc [96305.780000] r16-19 407b4778 407b4778 00125800 407b4778 [96305.780000] r20-23 0026b5d8 00000000 407b6778 00000001 [96305.780000] r24-27 00000001 00000006 417da390 00145288 [96305.780000] r28-31 00000001 fb0f9648 fb0f9000 407bb738 [96305.780000] sr0-3 0000010f 00000000 00000000 0000010f [96305.780000] sr4-7 0000010f 0000010f 0000010f 0000010f [96305.780000] [96305.780000] VZOUICununcqcqcqcqcqcrmunTDVZOUI [96305.780000] FPSR: 00001000001000000000000000000000 [96305.790000] FPER1: 00000000 [96305.790000] fr00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [96305.790000] fr04-07 0001e6200000f310 41b51f43614ccccd 415e848000000000 41b4a531614ccccd [96305.790000] fr08-11 428933a6c7464000 40c3880000000000 41cde2d44e000000 40aafc0000000000 [96305.790000] fr12-15 0000000000000000 0000000010175430 0000000000000000 0000000000000000 [96305.790000] fr16-19 fffffff410453810 106a409cffffffff 43ebebeb103306c7 0000000000000000 [96305.790000] fr20-23 45e69c6a25b7ea20 4180000010165ad8 0000000000000002 000000010002d930 [96305.790000] fr24-27 0000000200000000 4024000000000000 3fe0000000000000 bfb8298cc1440290 [96305.790000] fr28-31 3fd9f59ccfaeff5c 4118c1c000000000 412e848000000000 4008000000000000 [96305.790000] [96305.790000] IASQ: 0000010f 0000010f IAOQ: 406f20eb 406f20ef [96305.790000] IIR: 4aa60260 ISR: 0000010f IOR: 00000130 [96305.790000] CPU: 0 CR30: 12ad8000 CR31: 103f8000 [96305.790000] ORIG_R28: 00000000 [96305.790000] IAOQ[0]: 0x406f20eb [96305.790000] IAOQ[1]: 0x406f20ef [96305.790000] RP(r2): 0x406f20c3
I think this will be better handled by the HPPA team -- reassigning.
Created attachment 78825 [details, diff] elinks-0.11.0-ruby.patch Between 0.10.6 and 0.11.0, the authors of elinks apparently decided to not bother with string lengths anymore and let ruby do it, by (almost, but not quite entirely) switching from rb_str_new to rb_str_new2. This patch removes the only use of rb_str_new left in all of elinks 0.11.0. Also note that neither the bug nor the patch are HPPA specific.
Thanks for the patch :) I thought the problem was HPPA-specific because I wasn't able to reproduce it on my x86 machine. I was also a little confused by the kernel oops, thinking that problems in userspace apps shouldn't normally cause oopses.
> Between 0.10.6 and 0.11.0, the authors of elinks apparently decided to not > bother with string lengths anymore and let ruby do it, by (almost, but not > quite entirely) switching from rb_str_new to rb_str_new2. What are you talking about? ELinks used rb_str_new2 from the beginning. > This patch removes > the only use of rb_str_new left in all of elinks 0.11.0. Why? This actually reverts a bugfix and has no apparent justification. > Also note that neither the bug nor the patch are HPPA specific. Please explain how you know this. Here are some relevant events. 1. Initially, ELinks uses rb_str_new2 with a NUL-terminated string. 2. The string changes to one that isn't NUL-terminated. 3. Oops! We fix the code to use rb_str_new. 4. This bug report comes along. An ELinks developer who apparently wasn't familiar with the history of the Ruby code applies your patch, which reverts back to rb_str_new2. 5. Today, somebody reports corruption on #elinks. We track it down to using rb_str_new2 instead of rb_str_new. Why did you post that patch? Were you just shooting in the dark? I plan to revert it. Can you still reproduce the crash? Could I have the versions of Ruby and ELinks involved as well as a full backtrace? I really would appreciate that. Is it okay to re-open this report?
(In reply to comment #6) > What are you talking about? ELinks used rb_str_new2 from the beginning. Thanks for the update. A lot has changed for Gentoo/HPPA lately so I'll try and verify whether elinks builds without the patch soonish.
Created attachment 89795 [details] strace output without and with ~/.elinks/hooks.rb The command used was # strace -o elinks.out elinks http:/www.orkz.net/ Without hooks.rb, elinks merely crashes a few seconds after displaying the page and after receiving keyboard input. With hooks.rb, it never responds to keyboard input and can only be killed while its CPU usage skyrockets.
Created attachment 89797 [details] ~/.elinks/hooks.rb The hooks.rb was taken verbatim from [1]. Note that it is valid ruby but shouldn't do anything for the URL I loaded. jeroen@elmer ~ $ ruby -c .elinks/hooks.rb Syntax OK The version of ruby used here is: Fri Jun 16 05:39:53 2006 >>> dev-lang/ruby-1.8.4-r3 [1] http://edulinux.homeunix.org/elinks/
Do we have a solution for this? If it crashes both with the patch and without it, and no one has any idea of how to fix the problem, perhaps we should mask the 'ruby' USE flag for elinks on hppa?
(In reply to comment #10) > Do we have a solution for this? If it crashes both with the patch and without > it, and no one has any idea of how to fix the problem, perhaps we should mask > the 'ruby' USE flag for elinks on hppa? Ehrm, it always crashes without the patch. It never crashes *with* the patch. Hence the patch. 8-) You can make the patch conditional on `use hppa` if you like.
I have no idea what elinks' developers think of this bug now or what Gentoo's relations to them are like, but for HPPA this bug is fixed. I regret that things happened the way they did and I certainly hope that next time, any patches will be sent upstream for review first.
