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

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



Fabienne Ducroquet <fabiduc@gmail.com> writes:

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

I saw this on elinks-dev.

>     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
> exceptions:

This suggests ELinks has failed to disable echoing at the terminal.
Please verify this by looking up the tty that ELinks is using and
checking the modes with a command like this:

  stty -F /dev/pts/1 -a

ELinks should have enabled and disabled tty modes as follows:
-icrnl -ixon -icanon -iexten -echo isig tostop.  And also the
following, which may already be the default: -ignbrk -brkint
-parmrk -istrip -inlcr -igncr opost -echonl cs8 min=1 time=0.

If ELinks fails to set the modes, put a breakpoint at
src/terminal/kbd.c (setraw) and see whether execution gets there
and whether the tcsetattr call succeeds and has the intended
effect.  It may help if you use "set inferior-tty" in GDB to give
ELinks a tty different from the one where you run GDB; then you
can check the modes of that tty while ELinks is frozen.  Perhaps
run a "sleep 99999" on that tty so the shell won't try to read
From it while ELinks is using it.

> - 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,

ELinks catches SIGINT and translates it to an event internally.
It's odd though that it doesn't handle the event immediately.
Please show the value of *ditrm, especially ditrm->blocked.
Does execution ever reach in_kbd?

>     Should not this error "Cannot access memory at address 0x0"
> produce a segfault?

No, probably GCC has merely generated code that uses the stack in
a way that GDB cannot understand.  Recompile without optimization
and then you should see the real values in the debugger.

> 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.

It doesn't hang here, on Linux 2.6.  Instead, in
connect_to_af_unix, connect fails with ECONNREFUSED,
and ELinks retries that a few times and gives up.

Attachment: pgpssT6AndzOL.pgp
Description: PGP signature


Reply to: