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

Kalle Olavi Niemitalo <[email protected]>
Newsgroups gmane.comp.web.links,gmane.linux.debian.ports.hurd,gmane.comp.web.links.list
Message-ID <[email protected]>
Fabienne Ducroquet <[email protected]> writes:

> [ E-Mail sent to [email protected], CC'ed to
> [email protected] and [email protected] ]

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.

_______________________________________________
elinks-dev mailing list
[email protected]
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
signature.asc (application/pgp-signature, 188 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHZDrMHm9IGt60eMgRAlwRAJ99Cnxt46ImvexOS+N87UyYB6wHGwCbBc28
DSg/7Fcybc+i5qa1gjJp/tI=
=hfMm
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.