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:
pgpsTzzA9JXvC.pgp
Description: PGP signature