Not sure if my first attempt to email this worked, so I'll resend.
Apologies to all if it arrives twice.
elinks 0.11.3 compiled without much trouble on linux kernel 2.4.35.4
using old libc5 and with gcc -m386 (gcc version 2.95.3 20010315)
And it works nicely on sites with no/few frames, but the one important
site (my new bank!) let me log in once, with the server grumbling about
an error, then never again (did they see a problem at their end and fix
it?).
Now after entering my logon info (several items, for security), as
soon as the new screen starts to appear, elinks seg faults in frames.c.
An early compile without -disable--backtrace and without --enable-debug
(and with no dump attempted) gave the following, somewhat garbled by
overwriting on the screen :-
You last signed on: 5th Dec 2007 at
INTERNAL ERROR at frames.c:205: assertion doc_view->document failed!:54][S-J---]
/etc/script/elinks: line 437: 1717 Segmentation fault
$EXEC /usr/bin/elinks0113-older $OPTS $FNAM
A later dump of a debug version of 0.11.3 showed this:-
GDB 4.14 (i486-linux), Copyright 1995 Free Software Foundation, Inc...
Core was generated by /usr/bin/elinks-dbug'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/X11R6/lib/libX11.so.6.1...done.
Reading symbols from /usr/lib/libssl.so.0...done.
Reading symbols from /usr/lib/libcrypto.so.0...done.
Reading symbols from /usr/local/lib/libjs.so...done.
Reading symbols from /usr/lib/libgpm.so.1.10...done.
Reading symbols from /lib/libz.so.1.2.3...done.
Reading symbols from /lib/libc.so.5.4.38...done.
Reading symbols from /lib/libdl.so.1.9.5...done.
Reading symbols from /lib/libm.so.5.0.9...done.
Reading symbols from /lib/libncurses.so.3.0...done.
Reading symbols from /lib/ld-linux.so.1...done.
#0 0x808010d in format_frame (ses=0x8202f38, frame_desc=0x837d7a8,
o=0xbfffc50c, depth=0) at frames.c:206
206 doc_view->document->frame = frame_desc;
(gdb)
(gdb) print doc_view->document
$1 = (struct document *) 0x6e49202d
(gdb) print doc_view->document->frame
Cannot access memory at address 0x6e492125.
(gdb) bt
#0 0x808010d in format_frame (ses=0x8202f38, frame_desc=0x837d7a8,
o=0xbfffc50c, depth=0) at frames.c:206
#1 0x808027e in format_frames (ses=0x8202f38, fsd=0x837d780, op=0xbfffc5dc,
depth=0) at frames.c:247
#2 0x807b2c0 in render_document_frames (ses=0x8202f38, no_cache=0)
at renderer.c:452
#3 0x80e2537 in draw_formatted (ses=0x8202f38, rerender=1) at draw.c:354
#4 0x80cd1f7 in doc_loading_callback (download=0x82fc558, ses=0x8202f38)
at session.c:570
#5 0x80cd730 in file_loading_callback (download=0x82fc558, ftl=0x82fc530)
at session.c:641
#6 0x80a3b2c in notify_connection_callbacks (conn=0x82fc838)
at connection.c:427
#7 0x80a3bed in done_connection (conn=0x82fc838) at connection.c:444
#8 0x80a484a in abort_connection (conn=0x82fc838, state=S_OK)
at connection.c:730
#9 0x80c35db in http_end_request (conn=0x82fc838, state=S_OK, notrunc=0)
at http.c:484
#10 0x80c4c7d in read_http_data_done (conn=0x82fc838) at http.c:1140
#11 0x80c500e in read_http_data (socket=0x82c4b68, rb={addr = 0x8374f60,
addrno = 20464, triedno = 135024516, done = 0x1, dnsquery = 0x815bc50,
port = 9, ip_family = 89541}) at http.c:1331
#12 0x80a7749 in read_select (socket=0x82c4b68) at socket.c:875
#13 0x80a011e in select_loop (init=0x809f1e8 ) at select.c:283
#14 0x809f82c in main (argc=1, argv=0xbfffc8f4) at main.c:350
#15 0x80584be in _start ()
(gdb)
Another dump showed this (in part) :-
#0 0x80801f7 in format_frames (ses=0x8202f38, fsd=0x6c0062, op=0xbfffc50c,
depth=1) at frames.c:232
232 for (j = 0; j < fsd->box.height; j++) {
(gdb) print fsd
$1 = (struct frameset_desc *) 0x6c0062
(gdb) print fsd->box.height
Cannot access memory at address 0x6c0072.
(gdb)
(gdb) bt
#0 0x80801f7 in format_frames (ses=0x8202f38, fsd=0x6c0062, op=0xbfffc50c,
depth=1) at frames.c:232
#1 0x8080336 in format_frames (ses=0x8202f38, fsd=0x82673f8, op=0xbfffc5dc,
depth=0) at frames.c:272
#2 0x807b2c0 in render_document_frames (ses=0x8202f38, no_cache=0)
at renderer.c:452
etc. etc. (rest similar to the first dump)
It looks to me as though something is being freed (by garbage collection??),
possibly long before a later attempt to access it, but I'm no expert.
Any thoughts on how I might tackle this? Could I disable garbage
collection entirely, or am I wrong in thinking that might prevent the
crash?
I was hoping that a newer release might have corrected the problem, but
an interim elinks 0.12 still seg faults on this one web site (though I
haven't done a dump in this case).
--
R. T. Millar, [EMAIL PROTECTED]
.
___
elinks-users mailing list
elinks-users@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-users
