[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The Links/Links2/ELinks browsers are unusable on Debian GNU/Hurd

Le Fri, 14 Dec 2007 19:56:33 +0100, Fabienne Ducroquet
<fabiduc@gmail.com> a écrit :
> Le Thu, 13 Dec 2007 21:34:35 +0100, Fabienne Ducroquet

   The message to which I was replying is in the gmane archive but not
in the web archive of debian-hurd, so I resend its content, sorry for
the noise if you receive it several times:

[ E-Mail sent to debian-hurd@lists.debian.org, CC'ed to
elinks-dev@linuxfromscratch.org and links-list@linuxfromscratch.org ]


    I have tried to use the text web browsers Links (1.00~pre20-0.1,
from the debian repository), Links2 (2.1pre31-1, from the debian
repository) and ELinks (git/master from the git repository at
http://elinks.cz, there is no binary package for ELinks in Debian
hurd-i386 because of its Build-Dep on smbclient which is not available
for hurd-i386) on Debian GNU/Hurd, but they are totally unusable in text
mode, only Links2 in graphical mode works.

    In text mode they all three have the same behaviour: any key hit is
literally displayed on the screen, beginning at the position where the
cursor is (e.g. if I hit a letter it is displayed on the screen, if I
hit the right arrow ^[[C is printed on the screen ...), with a few
- <Enter> moves the cursor 1 line down instead of printing ^M or so,
- in the hurd console ^\ kills the program (shouldn't that produce a
  core dump too? I have limit CORE unlimited), but ^C does not work,
- inside gdb ^C interrupts the program (but not ^\). On an X terminal,
  neither ^C nor ^\ work, I have to kill the program with kill.
All the keys hit while the program was running are interpreted by the
shell after I killed the program.

    In fact there have been 2 or 3 times where the first keys hit have
been correctly interpreted before the browser became unusable (with
ELinks, but I tried the other ones less), but I didn't manage to
reproduce that and I don't know what could influence that.

    I firstly thought that this was just the hurd console which was not
fully supported, but then the "normal" keys such as the letters would
work, and the fact that it doesn't work with xterm or rxvt (i.e. all the
X terminal emulators I have tried) proves that the problem is elsewhere.
Do the other Hurd users have this issue or is there just something wrong
in my installation?

    I've tried to find what is wrong by compiling the programs in debug
mode and running gdb elinks (resp. links), then run, ^C to interrupt the
program and then bt, here are the results:

ELinks (0.13.GIT):
Program received signal SIGINT, Interrupt.
0x014c916c in mach_msg_trap () from /lib/libc.so.0.3
(gdb) bt
#0  0x014c916c in mach_msg_trap () from /lib/libc.so.0.3
#1  0x014c98b3 in mach_msg () from /lib/libc.so.0.3
#2  0x014cfd43 in _hurd_select () from /lib/libc.so.0.3
#3  0x015a7c8e in select () from /lib/libc.so.0.3
#4  0x080bfc29 in select_loop (init=0x80beb10 <init>) at select.c:252
#5  0x080bf1b8 in main (argc=Cannot access memory at address 0x0
) at main.c:361

Links (1.0~pre20-0.1):
Program received signal SIGINT, Interrupt.
0x011c716c in mach_msg_trap () from /lib/libc.so.0.3
(gdb) bt
#0  0x011c716c in mach_msg_trap () from /lib/libc.so.0.3
#1  0x011c78b3 in mach_msg () from /lib/libc.so.0.3
#2  0x011cdd43 in _hurd_select () from /lib/libc.so.0.3
#3  0x012a5c8e in select () from /lib/libc.so.0.3
#4  0x08086072 in select_loop (init=0x807c180 <init>) at select.c:353
#5  0x0807ba59 in main (argc=Cannot access memory at address 0x0
) at main.c:337

    In text mode Links2's behaviour is the same as Links' and ELinks',
but in graphical mode it works ... unless I run it from gdb.  If I run
gdb links2, then run -g, I can only access to local files, if I try to
access to another host there is an error "Host not found" (that's not a
network error, I can access to the same hosts with another browser at
the same time).  Then if I hit ^Z to suspend the program and see the
backtrace I have the same error than in text mode:
(gdb) bt
#0  0x013bb16c in mach_msg_trap () from /lib/libc.so.0.3
#1  0x013bb8b3 in mach_msg () from /lib/libc.so.0.3
#2  0x013c1d43 in _hurd_select () from /lib/libc.so.0.3
#3  0x01499c8e in select () from /lib/libc.so.0.3
#4  0x080b5d56 in select_loop (init=0x80a59b0 <init>) at select.c:423
#5  0x080a51d9 in main (argc=Cannot access memory at address 0x0
) at main.c:438

    If I continue the program after that, it does not work anymore:
nothing happens when I hit a key as the browser's window is focused, if
I hit a key as gdb's window is focused, it is just literally printed on
the screen like with *Links* in text mode (and interpreted by the shell
after gdb has been killed too), and I have to kill gdb as ^C and ^\
don't work anymore.  Outside of gdb there is none of these issues with
links2 -g, I can access to remote hosts or suspend it without causing
errors, and in gdb on Linux it works too.

    Should not this error "Cannot access memory at address 0x0" produce
a segfault?  Do you think that this error is why the browsers don't
work? Does someone have an idea about what could cause that?

    Thanks for your help.

PS: If you have the same problem than me, don't forget to verify that
the socket created in ~/.links or ~/.links2 or ~/.elinks has been
deleted after you have killed one of these programs, without that the
next time you launch it it will try to connect to a master instance
which does not exist through this socket and hang.


Reply to: