From fonseca at diku.dk  Sat Dec  1 05:15:44 2007
From: fonseca at diku.dk (Jonas Fonseca)
Date: Sat, 1 Dec 2007 13:15:44 +0100
Subject: [elinks-dev] http_proxy with username and password
In-Reply-To: <472911.55917.qm@web56111.mail.re3.yahoo.com>
References: <472911.55917.qm@web56111.mail.re3.yahoo.com>
Message-ID: <20071201121544.GB8302@diku.dk>

Simon Tan <simon1tan at yahoo.com> wrote Fri, Nov 30, 2007:
> I exported the http_proxy variable with username and password like so:
> export HTTP_PROXY=http://username:password at host:port.  Wget works, but
> elinks is unable to get online.  Is elinks not able to parse the
> variable?  If I enter the options and enter the proxy, username,
> password, elinks works fine. I understand there might be security
> concerns and stuff but if I save the password into a file(don't know
> if it's encrypted or not), same security concerns right.
> 
> It would still be a nice feature. Could that be implemented in future
> versions?  Thanks.

Since this is elinks-dev, here is a patch that extracts the user and
passwd from the HTTP_PROXY as an alternative to the options. It will
then be added as a "Proxy-Authorization: Basic ..." header.

Note, since I have no proxy server to test on I just tested it with some
debug prints and an online open proxy to see if the header variable was
set.

diff --git a/src/protocol/http/http.c b/src/protocol/http/http.c
index 26daefc..6a33580 100644
--- a/src/protocol/http/http.c
+++ b/src/protocol/http/http.c
@@ -630,7 +630,20 @@ http_send_header(struct socket *socket)
 		unsigned char *user = get_opt_str("protocol.http.proxy.user", NULL);
 		unsigned char *passwd = get_opt_str("protocol.http.proxy.passwd", NULL);
 
-		if (proxy_auth.digest) {
+		if (conn->uri->userlen)
+			user = memacpy(conn->uri->user, conn->uri->userlen);
+		else
+			user = stracpy(user);
+
+		if (conn->uri->passwordlen)
+			passwd = memacpy(conn->uri->password, conn->uri->passwordlen);
+		else
+			passwd = stracpy(passwd);
+
+		if (!passwd || !user) {
+			/* Failed to allocate! */
+
+		} else if (proxy_auth.digest) {
 			unsigned char *response;
 			int userlen = int_min(strlen(user), AUTH_USER_MAXLEN - 1);
 			int passwordlen = int_min(strlen(passwd), AUTH_PASSWORD_MAXLEN - 1);
@@ -671,6 +684,8 @@ http_send_header(struct socket *socket)
 				}
 			}
 		}
+		mem_free_if(user);
+		mem_free_if(passwd);
 	}
 
 	/* CONNECT: User-Agent does not reveal anything about the

-- 
Jonas Fonseca

From fabiduc at gmail.com  Thu Dec 13 13:34:35 2007
From: fabiduc at gmail.com (Fabienne Ducroquet)
Date: Thu, 13 Dec 2007 21:34:35 +0100
Subject: [elinks-dev] The Links/Links2/ELinks browsers are unusable on
	Debian GNU/Hurd
Message-ID: <20071213203434.GA7309@gmail.com>

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

    Hi,

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

-- 
Fabienne

From g68wmg402 at sneakemail.com  Fri Dec 14 21:06:55 2007
From: g68wmg402 at sneakemail.com (Rob)
Date: 15 Dec 2007 04:06:55 -0000
Subject: [elinks-dev] spidermonkey support in Mac OS X
Message-ID: <7965-56736@sneakemail.com>

Hi

In attempting to compile elinks for OS X
with Spidermonkey (ECMAScript) support, I
encountered a problem:

building elinks with ECMAScript support
requires that the system you are building
on have "ldconfig."

OS X does not have ldconfig, so configure
does not detect the Spidermonkey install.
Thus, it is currently impossible to
install elinks on OS X with Spidermonkey
/ECMAScript support.

From kon at iki.fi  Sat Dec 15 07:03:46 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Sat, 15 Dec 2007 16:03:46 +0200
Subject: [elinks-dev] spidermonkey support in Mac OS X
In-Reply-To: <7965-56736@sneakemail.com>
References: <7965-56736@sneakemail.com>
Message-ID: <87zlwcyrzx.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20071215/03ef455e/attachment.bin 

From kon at iki.fi  Sat Dec 15 13:36:21 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Sat, 15 Dec 2007 22:36:21 +0200
Subject: [elinks-dev] The Links/Links2/ELinks browsers are unusable on
	Debian GNU/Hurd
In-Reply-To: <20071213203434.GA7309@gmail.com>
References: <20071213203434.GA7309@gmail.com>
Message-ID: <87ir2zzoe2.fsf@Astalo.kon.iki.fi>

Fabienne Ducroquet <fabiduc at gmail.com> writes:

> [ E-Mail sent to debian-hurd at lists.debian.org, CC'ed to
> elinks-dev at linuxfromscratch.org and links-list at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20071215/02424b56/attachment.bin 

From qboosh at pld-linux.org  Sun Dec 16 04:03:29 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sun, 16 Dec 2007 12:03:29 +0100
Subject: [elinks-dev] [patch] locale-aware date format for ftp and file
Message-ID: <20071216110329.GA16279@stranger.qboosh.pl>

Hello,

The attached patch allows to localize the date format used for ftp and
file listings, like it's done in utilities like ls.
Especially "%b %e  %Y" format string used currently is specific to
English and some other languages usually don't put the day of month
between month and year - so I think the date format should be locale-aware.

Patch includes pl.po update as an example of localizing date format.
String containing just spaces is used as date replacement, so it should
be "translated" to proper number of spaces (equal length of formatted
date). I adjusted ftp.c so both files use strings with the same number
of spaces.


-- 
Jakub Bogusz    http://qboosh.pl/
-------------- next part --------------
--- elinks-0.11.3/src/util/file.c.orig	2007-12-02 01:03:26.631355000 +0100
+++ elinks-0.11.3/src/util/file.c	2007-12-02 01:19:06.416911036 +0100
@@ -461,16 +461,16 @@ stat_date(struct string *string, struct 
 
 		if (current_time > when + 6L * 30L * 24L * 60L * 60L
 		    || current_time < when - 60L * 60L)
-			fmt = "%b %e  %Y";
+			fmt = gettext("%b %e  %Y");
 		else
-			fmt = "%b %e %H:%M";
+			fmt = gettext("%b %e %H:%M");
 
 		add_date_to_string(string, fmt, &when);
 		add_char_to_string(string, ' ');
 		return;
 	}
 #endif
-	add_to_string(string, "             ");
+	add_to_string(string, gettext("             "));
 }
 
 
--- elinks-0.11.3/src/protocol/ftp/ftp.c.orig	2007-12-02 01:03:26.739361000 +0100
+++ elinks-0.11.3/src/protocol/ftp/ftp.c	2007-12-02 01:23:34.644196437 +0100
@@ -1147,7 +1147,7 @@ display_dir_entry(struct cache_entry *ca
 		time_t when = ftp_info->mtime;
 		struct tm *when_tm;
 	       	unsigned char *fmt;
-		unsigned char date[13];
+		unsigned char date[MAX_STR_LEN];
 		int wr;
 
 		if (ftp_info->local_time_zone)
@@ -1157,20 +1157,19 @@ display_dir_entry(struct cache_entry *ca
 
 		if (current_time > when + 6L * 30L * 24L * 60L * 60L
 		    || current_time < when - 60L * 60L)
-			fmt = "%b %e  %Y";
+			fmt = gettext("%b %e  %Y");
 		else
-			fmt = "%b %e %H:%M";
+			fmt = gettext("%b %e %H:%M");
 
-		wr = strftime(date, sizeof(date), fmt, when_tm);
-
-		while (wr < sizeof(date) - 1) date[wr++] = ' ';
-		date[sizeof(date) - 1] = '\0';
-		add_to_string(&string, date);
+		if (strftime(date, sizeof(date), fmt, when_tm) <= 0)
+			add_to_string(&string, gettext("             "));
+		else {
+			add_to_string(&string, date);
+			add_char_to_string(&string, ' ');
+		}
 	} else
 #endif
-	add_to_string(&string, "            ");
-
-	add_char_to_string(&string, ' ');
+	add_to_string(&string, gettext("             "));
 
 	if (ftp_info->type == FTP_FILE_DIRECTORY && colorize_dir) {
 		add_to_string(&string, "<font color=\"");
--- elinks-0.11.3/po/pl.po.orig	2007-04-15 22:51:02.000000000 +0200
+++ elinks-0.11.3/po/pl.po	2007-12-02 01:29:45.701341779 +0100
@@ -7428,6 +7428,18 @@
 msgid "Use EPSV instead of EPRT (passive vs active mode, IPv6 only)."
 msgstr "U?ywaj EPSV zamiast EPRT (tryb pasywny kontra aktywny, tylko IPv6)."
 
+#: src/protocol/ftp/ftp.c:1160 src/util/file.c:464
+msgid "%b %e  %Y"
+msgstr "%e.%m.%Y "
+
+#: src/protocol/ftp/ftp.c:1162 src/util/file.c:466
+msgid "%b %e %H:%M"
+msgstr "%e.%m %H:%M"
+
+#: src/protocol/ftp/ftp.c:1165 src/protocol/ftp/ftp.c:1172 src/util/file.c:473
+msgid "             "
+msgstr "             "
+
 #. name:
 #: src/protocol/gopher/gopher.c:46
 msgid "Gopher"

From fabiduc at gmail.com  Wed Dec 19 03:32:37 2007
From: fabiduc at gmail.com (Fabienne Ducroquet)
Date: Wed, 19 Dec 2007 11:32:37 +0100
Subject: [elinks-dev] The Links/Links2/ELinks browsers are unusable on
	Debian GNU/Hurd
References: <20071213203434.GA7309@gmail.com>
	<87ir2zzoe2.fsf@Astalo.kon.iki.fi> <fk987c$pjp$1@ger.gmane.org>
	<fk9m6o$929$1@ger.gmane.org>
Message-ID: <fkas5a$28p$1@ger.gmane.org>

Le Wed, 19 Dec 2007 00:44:46 +0100, Fabienne Ducroquet
<fabiduc at gmail.com> a ?crit :
>  and more precisely, that seems to happen after
> set_handlers has been called with read_func = 0, write_func = 0 and
> error_func = &free_itrm (or &free_trm).  After that, all the calls to

    I think that this is normal (that the error happens before that).
In ELinks, I've found something anormal during the execution of
itrm_queue_event on Hurd: it jumps from line 116
	if (!itrm->out.queue.len && can_write(itrm->out.sock)) {
to line 119 (which is inside the if) without executing lines 117-118
		w = safe_write(itrm->out.sock, data, len);
		if (w <= 0 && HPUX_PIPE) {
Then it executes lines 124-141 as w is still 0 whereas it should
have been modified at line 117.

In Links 1.00pre20 there is something similar during the execution of
queue_event (in kbd.c): after the test line 69
	if (!itrm->eqlen && can_write(itrm->sock_out) && (w =
write(itrm->sock_out, data, len)) <= 0) {
it jumps to line 72 (inside the if)
			return;
without executing line 71, and then the execution of the function
continues line 74 to 80 as w is still 0.  I don't know whether the
command w = write(...) in the test is executed or not.

-- 
Fabienne


From kon at iki.fi  Wed Dec 19 15:40:10 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Thu, 20 Dec 2007 00:40:10 +0200
Subject: [elinks-dev] The Links/Links2/ELinks browsers are unusable on
	Debian GNU/Hurd
In-Reply-To: <fk987c$pjp$1@ger.gmane.org>
References: <20071213203434.GA7309@gmail.com>
	<87ir2zzoe2.fsf@Astalo.kon.iki.fi> <fk987c$pjp$1@ger.gmane.org>
Message-ID: <87wsra9ulx.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20071220/ea5ea272/attachment.bin 

From fabiduc at gmail.com  Wed Dec 19 19:38:12 2007
From: fabiduc at gmail.com (Fabienne Ducroquet)
Date: Thu, 20 Dec 2007 03:38:12 +0100
Subject: [elinks-dev] The Links/Links2/ELinks browsers are unusable
	on	Debian GNU/Hurd
In-Reply-To: <87wsra9ulx.fsf@Astalo.kon.iki.fi>
References: <20071213203434.GA7309@gmail.com>
	<87ir2zzoe2.fsf@Astalo.kon.iki.fi> <fk987c$pjp$1@ger.gmane.org>
	<87wsra9ulx.fsf@Astalo.kon.iki.fi>
Message-ID: <20071220023812.GA22464@gmail.com>

On Thu, Dec 20, 2007 at 12:40:10AM +0200, Kalle Olavi Niemitalo wrote:
> free_itrm should be called only if an error or EOF occurs in
> terminal handling, or when ELinks is exiting.

    Did you receive all my replies? I sent 3 successive replies through
gmane during my investigation but I see only one in elinks-dev web
archive.
    I did not detail what I've done in these mails, I will do that here
(it's rather long with the output of gdb, sorry).
    As threads[i].error_func is set by set_handlers, I've put a
breakpoint at set_handlers and compared what happens on Hurd and Linux
in the same conditions (run elinks -no-home about:blank on a terminal on
which I've done sleep 99999 and which I don't touch during the test).
On Linux set_handlers is called only 2 times before ELinks displays the
blank page I've requested and waits for further input, the result with
backtraces at each break is:

(gdb) run -no-home about:blank
Starting program: /home/fabi/prog/bin/elinks-bin -no-home about:blank
[Thread debugging using libthread_db enabled]
[New Thread 0xb737c930 (LWP 21627)]
[Switching to Thread 0xb737c930 (LWP 21627)]

Breakpoint 2, set_handlers (fd=0, read_func=0x8106ae0 <in_kbd>, write_func=0, 
    error_func=0x8105970 <free_itrm>, data=0x81c0d38) at select.c:144
144		assertm(fd >= 0 && fd < FD_SETSIZE,
(gdb) bt
#0  set_handlers (fd=0, read_func=0x8106ae0 <in_kbd>, write_func=0, 
    error_func=0x8105970 <free_itrm>, data=0x81c0d38) at select.c:144
#1  0x0810565c in handle_itrm_stdin (itrm=<value optimized out>) at kbd.c:1193
#2  0x08105e19 in handle_trm (std_in=0, std_out=1, sock_in=1, sock_out=7, 
    ctl_in=0, init_string=0x82a69e8, init_len=12, remote=0) at kbd.c:330
#3  0x0810b59f in attach_terminal (in=0, out=1, ctl=0, info=0x82a69e8, len=12)
    at terminal.c:371
#4  0x080cf578 in init () at main.c:239
#5  0x080d0071 in select_loop (init=0x80cef20 <init>) at select.c:204
#6  0x080cf6b8 in main (argc=3, argv=0xbf945444) at main.c:361
(gdb) c
Continuing.

Breakpoint 2, set_handlers (fd=6, read_func=0x8104890 <in_term>, write_func=0, 
    error_func=0x810ae90 <destroy_terminal>, data=0x82f7e28) at select.c:144
144		assertm(fd >= 0 && fd < FD_SETSIZE,
(gdb) bt
#0  set_handlers (fd=6, read_func=0x8104890 <in_term>, write_func=0, 
    error_func=0x810ae90 <destroy_terminal>, data=0x82f7e28) at select.c:144
#1  0x0810b452 in init_term (fdin=6, fdout=1) at terminal.c:101
#2  0x0810b5b3 in attach_terminal (in=0, out=1, ctl=0, info=0x82a69e8, len=12)
    at terminal.c:373
#3  0x080cf578 in init () at main.c:239
#4  0x080d0071 in select_loop (init=0x80cef20 <init>) at select.c:204
#5  0x080cf6b8 in main (argc=3, argv=0xbf945444) at main.c:361
(gdb) c
Continuing.


     On Hurd there are 9 calls to set_handlers before ELinks displays
the about:blank (and I have to kill gdb after that because it does not
understand ^C).  The result is:

(gdb) run -no-home about:blank
Starting program: /home/fabi/hurd/bin/elinks -no-home about:blank

Breakpoint 2, set_handlers (fd=0, read_func=0x80c1a10 <in_kbd>, write_func=0, 
    error_func=0x80c0970 <free_itrm>, data=0x8187f00) at select.c:144
144		assertm(fd >= 0 && fd < FD_SETSIZE,
(gdb) bt
#0  set_handlers (fd=0, read_func=0x80c1a10 <in_kbd>, write_func=0, 
    error_func=0x80c0970 <free_itrm>, data=0x8187f00) at select.c:144
#1  0x080c06cb in handle_itrm_stdin (itrm=0x8187f00) at kbd.c:1193
#2  0x080c0d6a in handle_trm (std_in=0, std_out=1, sock_in=1, sock_out=7, 
    ctl_in=0, init_string=0x8187dd0, init_len=12, remote=0) at kbd.c:330
#3  0x080c5aeb in attach_terminal (in=0, out=1, ctl=0, info=0x8187dd0, len=12)
    at terminal.c:371
#4  0x0809de88 in init () at main.c:239
#5  0x0809e8f7 in select_loop (init=0x809d900 <init>) at select.c:204
#6  0x0809df98 in main (argc=) at main.c:361
(gdb) c
Continuing.

Breakpoint 2, set_handlers (fd=7, read_func=0, 
    write_func=0x80c1090 <itrm_queue_write>, error_func=0x80c0970 <free_itrm>, 
    data=0x8187f00) at select.c:144
144		assertm(fd >= 0 && fd < FD_SETSIZE,
(gdb) bt
#0  set_handlers (fd=7, read_func=0, write_func=0x80c1090 <itrm_queue_write>, 
    error_func=0x80c0970 <free_itrm>, data=0x8187f00) at select.c:144
#1  0x080c0bd0 in itrm_queue_event (itrm=0x8187f00, data=0x1020b28 "", len=320)
    at kbd.c:137
#2  0x080c0dff in handle_trm (std_in=0, std_out=1, sock_in=1, sock_out=7, 
    ctl_in=0, init_string=0x8187dd0, init_len=12, remote=0) at kbd.c:344
#3  0x080c5aeb in attach_terminal (in=0, out=1, ctl=0, info=0x8187dd0, len=12)
    at terminal.c:371
#4  0x0809de88 in init () at main.c:239
	info = {magic = 777777777, source = 0x8187dd0 "about:blank", length = 12}
#5  0x0809e8f7 in select_loop (init=0x809d900 <init>) at select.c:204
#6  0x0809df98 in main (argc=) at main.c:361
(gdb) c
Continuing.

Breakpoint 2, set_handlers (fd=7, read_func=0, 
    write_func=0x80c1090 <itrm_queue_write>, error_func=0x80c0970 <free_itrm>, 
    data=0x8187f00) at select.c:144
144		assertm(fd >= 0 && fd < FD_SETSIZE,
(gdb) bt
#0  set_handlers (fd=7, read_func=0, write_func=0x80c1090 <itrm_queue_write>, 
    error_func=0x80c0970 <free_itrm>, data=0x8187f00) at select.c:144
#1  0x080c0bd0 in itrm_queue_event (itrm=0x8187f00, data=0x8187dd0 "about:blank", 
    len=12) at kbd.c:137
#2  0x080c0e10 in handle_trm (std_in=0, std_out=1, sock_in=1, sock_out=7, 
    ctl_in=0, init_string=0x8187dd0, init_len=12, remote=0) at kbd.c:345
#3  0x080c5aeb in attach_terminal (in=0, out=1, ctl=0, info=0x8187dd0, len=12)
    at terminal.c:371
#4  0x0809de88 in init () at main.c:239
#5  0x0809e8f7 in select_loop (init=0x809d900 <init>) at select.c:204
#6  0x0809df98 in main (argc=) at main.c:361
(gdb) c
Continuing.

Breakpoint 2, set_handlers (fd=6, read_func=0x80bfab0 <in_term>, write_func=0, 
    error_func=0x80c53f0 <destroy_terminal>, data=0x8188180) at select.c:144
144		assertm(fd >= 0 && fd < FD_SETSIZE,
(gdb) bt
#0  set_handlers (fd=6, read_func=0x80bfab0 <in_term>, write_func=0, 
    error_func=0x80c53f0 <destroy_terminal>, data=0x8188180) at select.c:144
#1  0x080c5981 in init_term (fdin=6, fdout=1) at terminal.c:101
#2  0x080c5afe in attach_terminal (in=0, out=1, ctl=0, info=0x8187dd0, len=12)
    at terminal.c:373
#3  0x0809de88 in init () at main.c:239
#4  0x0809e8f7 in select_loop (init=0x809d900 <init>) at select.c:204
#5  0x0809df98 in main (argc=0, argv=0x0) at main.c:361
(gdb) c
Continuing.

Breakpoint 2, set_handlers (fd=7, read_func=0, write_func=0, 
    error_func=0x80c0970 <free_itrm>, data=0x8187f00) at select.c:144
144		assertm(fd >= 0 && fd < FD_SETSIZE,
(gdb) bt
#0  set_handlers (fd=7, read_func=0, write_func=0, 
    error_func=0x80c0970 <free_itrm>, data=0x8187f00) at select.c:144
#1  0x080c11dc in itrm_queue_write (itrm=0x8187f00) at kbd.c:97
#2  0x0809ea8b in select_loop (init=0x809d900 <init>) at select.c:297
#3  0x0809df98 in main (argc=) at main.c:361
(gdb) c
Continuing.

Breakpoint 1, free_itrm (itrm=0x8187f00) at kbd.c:403
403		if (!itrm) return;
(gdb) bt
#0  free_itrm (itrm=0x8187f00) at kbd.c:403
#1  0x0809eac9 in select_loop (init=0x809d900 <init>) at select.c:305
#2  0x0809df98 in main (argc=) at main.c:361
(gdb) c
Continuing.

Breakpoint 2, set_handlers (fd=0, read_func=0, write_func=0, error_func=0, 
    data=0x0) at select.c:144
144		assertm(fd >= 0 && fd < FD_SETSIZE,
(gdb) bt
#0  set_handlers (fd=0, read_func=0, write_func=0, error_func=0, data=0x0)
    at select.c:144
#1  0x080c09c4 in free_itrm (itrm=0x8187f00) at kbd.c:431
#2  0x0809eac9 in select_loop (init=0x809d900 <init>) at select.c:305
#3  0x0809df98 in main (argc=0, argv=0x0) at main.c:361
(gdb) c
Continuing.

Breakpoint 2, set_handlers (fd=1, read_func=0, write_func=0, error_func=0, 
    data=0x0) at select.c:144
144		assertm(fd >= 0 && fd < FD_SETSIZE,
(gdb) bt
#0  set_handlers (fd=1, read_func=0, write_func=0, error_func=0, data=0x0)
    at select.c:144
#1  0x080c09d8 in free_itrm (itrm=0x8187f00) at kbd.c:432
#2  0x0809eac9 in select_loop (init=0x809d900 <init>) at select.c:305
#3  0x0809df98 in main (argc=) at main.c:361
(gdb) c
Continuing.

Breakpoint 2, set_handlers (fd=1, read_func=0, write_func=0, error_func=0, 
    data=0x0) at select.c:144
144		assertm(fd >= 0 && fd < FD_SETSIZE,
(gdb) bt
#0  set_handlers (fd=1, read_func=0, write_func=0, error_func=0, data=0x0)
    at select.c:144
#1  0x080c09ec in free_itrm (itrm=0x8187f00) at kbd.c:433
#2  0x0809eac9 in select_loop (init=0x809d900 <init>) at select.c:305
#3  0x0809df98 in main (argc=) at main.c:361
(gdb) c
Continuing.

Breakpoint 2, set_handlers (fd=7, read_func=0, write_func=0, error_func=0, 
    data=0x0) at select.c:144
144		assertm(fd >= 0 && fd < FD_SETSIZE,
(gdb) bt
#0  set_handlers (fd=7, read_func=0, write_func=0, error_func=0, data=0x0)
    at select.c:144
#1  0x080c0a00 in free_itrm (itrm=0x8187f00) at kbd.c:434
#2  0x0809eac9 in select_loop (init=0x809d900 <init>) at select.c:305
#3  0x0809df98 in main (argc=) at main.c:361
(gdb) c
Continuing.



    There is no problem with the first call to set_handlers (the same as
on Linux), but the second one comes from itrm_queue_event which does not
call set_handlers on Linux.  Then I put a breakpoint at itrm_queue_event
to compare its execution on Hurd and Linux, the part of code concerned
is (in src/terminal/kbd.c):

109 void
110 itrm_queue_event(struct itrm *itrm, unsigned char *data, int len)
111 {
112 	int w = 0;
113
114 	if (!len) return;
115
116 	if (!itrm->out.queue.len && can_write(itrm->out.sock)) {
117 		w = safe_write(itrm->out.sock, data, len);
118 		if (w <= 0 && HPUX_PIPE) {
119 			register_bottom_half(free_itrm, itrm);
120 			return;
121 		}
122 	}
123
124 	if (w < len) {
	...
141	}
142 }

set_handlers is called in the if, but there is no problem during the
execution of this part of code.  On Linux the line 117 is executed, then
the 2 tests (w <= 0 && HPUX_PIPE) and (w < len) fail (because w == len)
and the function exits. Here is what the step by step execution of this
function gives on Hurd:

(gdb) run -no-home about:blank
Starting program: /home/fabi/hurd/elinks/src/elinks -no-home about:blank

Breakpoint 1, itrm_queue_event (itrm=0x8187f00, data=0x1020b28 "", len=320)
    at kbd.c:114
114		if (!len) return;
(gdb) n
116		if (!itrm->out.queue.len && can_write(itrm->out.sock)) {
(gdb) n
119				register_bottom_half(free_itrm, itrm);
(gdb) n
124		if (w < len) {
(gdb) print w
$1 = 0

The execution continues normally, there is a if (!c) {
free_itrm(itrm);... but free_itrm is not executed yet because c<>0 here.
As you can see, there is something wrong there, and I think that it is
that which causes ELinks to call free_itrm later (and that at that
moment the call to free_itrm is justified).  And indeed, I've just tried
to cause the same behaviour on Linux by applying the following patch:

diff --git a/src/terminal/kbd.c b/src/terminal/kbd.c
index 1d34232..5868062 100644
--- a/src/terminal/kbd.c
+++ b/src/terminal/kbd.c
@@ -114,11 +114,11 @@ itrm_queue_event(struct itrm *itrm, unsigned char *data, int len)
 	if (!len) return;
 
 	if (!itrm->out.queue.len && can_write(itrm->out.sock)) {
-		w = safe_write(itrm->out.sock, data, len);
-		if (w <= 0 && HPUX_PIPE) {
+/*		w = safe_write(itrm->out.sock, data, len);
+		if (w <= 0 && HPUX_PIPE) {*/
 			register_bottom_half(free_itrm, itrm);
-			return;
-		}
+		/*	return;
+		}*/
 	}
 
 	if (w < len) {

    The results are quite good, i.e. it breaks everything, though the
behaviour is not exactly the same as on Hurd (the screen remains blank
whereas on Hurd the page requested is displayed), there is a call to
free_itrm too.
    And now, I have no idea what causes the execution of itrm_queue_event
to be wrong.

> However, I don't know the origin of that code

    The function select_loop seems to mostly come directly from Links.
    I have no opinion for the rest of your e-mail, I did not understand :)

-- 
Fabienne

From kon at iki.fi  Wed Dec 19 21:29:51 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Thu, 20 Dec 2007 06:29:51 +0200
Subject: [elinks-dev] The Links/Links2/ELinks browsers are unusable
	on	Debian GNU/Hurd
In-Reply-To: <20071220023812.GA22464@gmail.com>
References: <20071213203434.GA7309@gmail.com>
	<87ir2zzoe2.fsf@Astalo.kon.iki.fi> <fk987c$pjp$1@ger.gmane.org>
	<87wsra9ulx.fsf@Astalo.kon.iki.fi> <20071220023812.GA22464@gmail.com>
Message-ID: <87prx29ef4.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20071220/a792720a/attachment.bin 

From fabiduc at gmail.com  Thu Dec 20 15:50:26 2007
From: fabiduc at gmail.com (Fabienne Ducroquet)
Date: Thu, 20 Dec 2007 23:50:26 +0100
Subject: [elinks-dev] The Links/Links2/ELinks browsers are unusable
	on	Debian GNU/Hurd
In-Reply-To: <87prx29ef4.fsf@Astalo.kon.iki.fi>
References: <20071213203434.GA7309@gmail.com>
	<87ir2zzoe2.fsf@Astalo.kon.iki.fi> <fk987c$pjp$1@ger.gmane.org>
	<87wsra9ulx.fsf@Astalo.kon.iki.fi>
	<20071220023812.GA22464@gmail.com>
	<87prx29ef4.fsf@Astalo.kon.iki.fi>
Message-ID: <20071220225026.GA9244@gmail.com>

On Thu, Dec 20, 2007 at 06:29:51AM +0200, Kalle Olavi Niemitalo wrote:
> > 114		if (!len) return;
> > (gdb) n
> > 116		if (!itrm->out.queue.len && can_write(itrm->out.sock)) {
> > (gdb) n
> > 119				register_bottom_half(free_itrm, itrm);
> > (gdb) n
> > 124		if (w < len) {
> 
> Recompile without optimization to see what really happens here.

(gdb) run -no-home
Starting program: /home/fabi/hurd/elinks/src/elinks -no-home

Breakpoint 1, itrm_queue_event (itrm=0x81a1f40, data=0x1020b18 "", len=320)
    at kbd.c:112
112		int w = 0;
(gdb) n
114		if (!len) return;
(gdb) n
116		if (!itrm->out.queue.len && can_write(itrm->out.sock)) {
(gdb) n
124		if (w < len) {
(gdb) n
125			int left = len - w;
(gdb) n
126			unsigned char *c = mem_realloc(itrm->out.queue.data,
(gdb) n
129			if (!c) {
(gdb) n
134			itrm->out.queue.data = c;
(gdb) n
135			memcpy(itrm->out.queue.data + itrm->out.queue.len, data + w, left);
(gdb) n
136			itrm->out.queue.len += left;
(gdb) n
137			set_handlers(itrm->out.sock,
(gdb) n
142	}
(gdb) n
handle_trm (std_in=0, std_out=1, sock_in=1, sock_out=7, ctl_in=0, 
    init_string=0x81a1dd0, init_len=0, remote=0) at kbd.c:345
345		itrm_queue_event(itrm, (char *) init_string, init_len);

    The test line 116 fails here and not on Linux.  I still don't
understand why gdb says that it goes to the line 119
(check_bottom_halves) with optimization?
    With a breakpoint at can_read_or_write:

(gdb) run -no-home
Starting program: /home/fabi/hurd/elinks/src/elinks -no-home

Breakpoint 1, itrm_queue_event (itrm=0x81a1f40, data=0x1020b18 "", len=320)
    at kbd.c:112
112		int w = 0;
(gdb) n
114		if (!len) return;
(gdb) n
116		if (!itrm->out.queue.len && can_write(itrm->out.sock)) {
(gdb) print *itrm
$1 = {in = {std = 0, sock = 1, ctl = 0, queue = {data = 0x81a1fd0 "", 
      len = 0}}, out = {std = 1, sock = 7, queue = {data = 0x0, len = 0}}, 
  timer = 0x0, t = {c_iflag = 10240, c_oflag = 3, c_cflag = 19201, 
    c_lflag = 4194499, c_cc = "\004??\177\027\025\022?\003???????\001\000??", 
    __ispeed = 38400, __ospeed = 38400}, mouse_h = 0x0, orig_title = 0x0, 
  blocked = 0, altscreen = 1, touched_title = 0, remote = 0}
(gdb) n

Breakpoint 2, can_read_or_write (fd=7, write=1) at select.c:319
319		struct timeval tv = {0, 0};
(gdb) n
321		fd_set *rfds = NULL;
(gdb) n
322		fd_set *wfds = NULL;
(gdb) n
324		FD_ZERO(&fds);
(gdb) n
325		FD_SET(fd, &fds);
(gdb) n
327		if (write)
(gdb) n
328			wfds = &fds;
(gdb) n
332		return select(fd + 1, rfds, wfds, NULL, &tv);
(gdb) print wfds
$2 = (fd_set *) 0x1020a6c
(gdb) print rfds
$3 = (fd_set *) 0x0
(gdb) print &tv
$4 = (struct timeval *) 0x1020a8c
(gdb) print select(8,0x0,0x1020a6c,0x0,0x1020a8c)
$5 = 0
(gdb) n
333	}
(gdb) n
can_write (fd=7) at select.c:345
345	}
(gdb) n
itrm_queue_event (itrm=0x81a1f40, data=0x1020b18 "", len=320) at kbd.c:124
124		if (w < len) {
(gdb) n
125			int left = len - w;

> I mean, the compiler might merely have decided to load the
> address of free_itrm into a register at that point, or something
> like that.

    But how could I see that?

> > As you can see, there is something wrong there,
> 
> I don't see that.

    You are probably more experienced than me in that sort of thing, for
me that seems at least very weird. :-)

> So the patch doesn't reveal anything.

   It's true, I had not observed enough what it does.

> Instead, you should find out why the select function is reporting
> an exceptional state for the file descriptor.

   According to the gdb output above select in can_read_or_write(7,1)
returns 0 whereas on Linux it returns 1 in the same conditions, but why,
I don't know.

> I suggest you use rpctrace to find whether any io_select is
> returning the SELECT_URG flag in select_type, and from which
> server that reply comes. 

    I tried rpctrace elinks but I don't know what to look for in the
output...  There are lines such as:

task2573->vm_deallocate (21331968 4096) = 0 
  88->io_select_request (2)task2573->mach_port_destroy (pn{ 25}) = 0 
reply(94:io_select_request)->io_select_reply (0 2);
  72->io_write_request ("^[[1;1H" -1) = 0 6
  52->io_select_request (5)task2573->mach_port_allocate (3) = 0 pn{ 29}
task2573->mach_port_move_member (pn{ 25} pn{ 29}) = 0 
  86->io_select_request (5)task2573->mach_port_move_member (pn{ 27} pn{ 29}) = 0 
  88->io_select_request (6)task2573->mach_port_move_member (pn{ 28} pn{ 29}) = 0 
reply(96:io_select_request)->io_select_reply (0 2);
task2573->mach_port_destroy (pn{ 25}) = 0 

    What must I look here? ?the numbers between parenthesis after
io_select_reply (in that case, they are always (0 1) or (0 2) or (0 0))?
something completely different?

> Also try putting the NULLs in ELinks
> like I mentioned in the previous message.

Something like the following patch?  It seems to work, but perhaps it
breaks something else.

Fabienne.

diff --git a/src/main/select.c b/src/main/select.c
index aab5349..7311c6f 100644
--- a/src/main/select.c
+++ b/src/main/select.c
@@ -33,6 +33,7 @@
 #include "main/select.h"
 #include "main/timer.h"
 #include "osdep/signals.h"
+#include "terminal/kbd.h"
 #include "terminal/terminal.h"
 #include "util/error.h"
 #include "util/memory.h"
@@ -148,7 +149,9 @@ set_handlers(int fd, select_handler_T read_func, select_handler_T write_func,
 #endif
 	threads[fd].read_func = read_func;
 	threads[fd].write_func = write_func;
-	threads[fd].error_func = error_func;
+	threads[fd].error_func = NULL;
+	if (error_func != (select_handler_T) free_itrm)
+		threads[fd].error_func = error_func;
 	threads[fd].data = data;
 
 	if (read_func) {
diff --git a/src/terminal/kbd.c b/src/terminal/kbd.c
index 1d34232..c2ff503 100644
--- a/src/terminal/kbd.c
+++ b/src/terminal/kbd.c
@@ -43,7 +43,6 @@
 
 struct itrm *ditrm = NULL;
 
-static void free_itrm(struct itrm *);
 static void in_kbd(struct itrm *);
 static void in_sock(struct itrm *);
 static int process_queue(struct itrm *);
@@ -397,7 +396,7 @@ block_itrm(void)
 }
 
 
-static void
+void
 free_itrm(struct itrm *itrm)
 {
 	if (!itrm) return;
diff --git a/src/terminal/kbd.h b/src/terminal/kbd.h
index e886f8c..bf95976 100644
--- a/src/terminal/kbd.h
+++ b/src/terminal/kbd.h
@@ -121,6 +121,7 @@ void itrm_queue_event(struct itrm *itrm, unsigned char *data, int len);
 void block_itrm(void);
 int unblock_itrm(void);
 void free_all_itrms(void);
+void free_itrm(struct itrm *);
 void resize_terminal(void);
 void dispatch_special(unsigned char *);
 void kbd_ctrl_c(void);

From kon at iki.fi  Thu Dec 20 18:04:06 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Fri, 21 Dec 2007 03:04:06 +0200
Subject: [elinks-dev] The Links/Links2/ELinks browsers are unusable
	on	Debian GNU/Hurd
In-Reply-To: <20071220225026.GA9244@gmail.com>
References: <20071213203434.GA7309@gmail.com>
	<87ir2zzoe2.fsf@Astalo.kon.iki.fi> <fk987c$pjp$1@ger.gmane.org>
	<87wsra9ulx.fsf@Astalo.kon.iki.fi> <20071220023812.GA22464@gmail.com>
	<87prx29ef4.fsf@Astalo.kon.iki.fi> <20071220225026.GA9244@gmail.com>
Message-ID: <87d4t06epl.fsf@Astalo.kon.iki.fi>

Fabienne Ducroquet <fabiduc at gmail.com> writes:

> On Thu, Dec 20, 2007 at 06:29:51AM +0200, Kalle Olavi Niemitalo wrote:
>> I mean, the compiler might merely have decided to load the
>> address of free_itrm into a register at that point, or something
>> like that.
>
>     But how could I see that?

By disassembling the function and then perhaps comparing values
of the program counter to the disassembly.

>> Instead, you should find out why the select function is reporting
>> an exceptional state for the file descriptor.
>
>    According to the gdb output above select in can_read_or_write(7,1)
> returns 0 whereas on Linux it returns 1 in the same conditions, but why,
> I don't know.

I'm not sure, but it seems to me that _hurd_select in glibc is
using the select timeout as a timeout for the io_select RPC.
So when the timeout is zero, _hurd_select has no time to receive
the reply that the file descriptor is ready.  You might perhaps
verify this hypothesis by increasing the timeout in
can_read_or_write.  The behaviour of the Hurd here may be
contrary to POSIX, but still, I don't see why that would cause
free_itrm to be called too soon.

>     What must I look here? ?the numbers between parenthesis after
> io_select_reply (in that case, they are always (0 1) or (0 2) or (0 0))?
> something completely different?

hurd_types.h defines SELECT_URG as 4.  In io_select_reply, the
first value is return_code: kern_return_t, and the second value
is select_result: int.  Is the second value ever 4 or greater?

If you find that, take note of the port to which the original
io_select_request was sent, and search back to find how ELinks
got a send right to that.  In particular, did the send right come
From a socket_create response?

If the parameters of io_select_reply really are always (0 1),
(0 2), or (0 0), then I think you'll have to trace inside
_hurd_select in glibc and see why it's reporting an exception
on the file descriptor even though it did not receive any
io_select_reply that includes SELECT_URG.  In the source code,
there appear to be some error situations that default to "type =
SELECT_ALL;".  You might put breakpoints on those, a breakpoint
with condition "msg.success.result & 4" on "int had = got;",
and a breakpoint on "got++;" below "if (type & SELECT_URG)".

> Something like the following patch?  It seems to work, but perhaps it
> breaks something else.

Probably it doesn't break anything else, but anyway I meant
changing the callers of set_handlers, rather than the function
itself.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20071221/b5fd9e1d/attachment.bin 

From fabiduc at gmail.com  Thu Dec 20 19:02:40 2007
From: fabiduc at gmail.com (Fabienne Ducroquet)
Date: Fri, 21 Dec 2007 03:02:40 +0100
Subject: [elinks-dev] The Links/Links2/ELinks browsers are unusable
	on	Debian GNU/Hurd
References: <20071213203434.GA7309@gmail.com>
	<87ir2zzoe2.fsf@Astalo.kon.iki.fi> <fk987c$pjp$1@ger.gmane.org>
	<87wsra9ulx.fsf@Astalo.kon.iki.fi> <20071220023812.GA22464@gmail.com>
	<87prx29ef4.fsf@Astalo.kon.iki.fi> <20071220225026.GA9244@gmail.com>
	<87d4t06epl.fsf@Astalo.kon.iki.fi>
Message-ID: <fkf6s9$l2a$1@ger.gmane.org>

Le Fri, 21 Dec 2007 03:04:06 +0200, Kalle Olavi Niemitalo <kon at iki.fi> a
?crit :
> Probably it doesn't break anything else, but anyway I meant
> changing the callers of set_handlers, rather than the function
> itself.

    OK, I remark that I've forgotten the tests on error_func further in
the function anyway, I will not have the possibility to look at that
before 2.5 weeks (at least) but I will try to do that and the other
things you suggest in your message at that moment (if nobody else
decides to do it in the meantime :-).

-- 
Fabienne


From kon at iki.fi  Wed Dec 26 08:44:37 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Wed, 26 Dec 2007 17:44:37 +0200
Subject: [elinks-dev] The Links/Links2/ELinks browsers are unusable on
 Debian GNU/Hurd
In-Reply-To: <fkf6s9$l2a$1@ger.gmane.org>
References: <20071213203434.GA7309@gmail.com>
	<87ir2zzoe2.fsf@Astalo.kon.iki.fi> <fk987c$pjp$1@ger.gmane.org>
	<87wsra9ulx.fsf@Astalo.kon.iki.fi> <20071220023812.GA22464@gmail.com>
	<87prx29ef4.fsf@Astalo.kon.iki.fi> <20071220225026.GA9244@gmail.com>
	<87d4t06epl.fsf@Astalo.kon.iki.fi> <fkf6s9$l2a$1@ger.gmane.org>
Message-ID: <87zlvxqx3u.fsf_-_@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20071226/40a1a374/attachment.bin 

From kon at iki.fi  Thu Dec 27 17:00:55 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Fri, 28 Dec 2007 02:00:55 +0200
Subject: [elinks-dev] The Links/Links2/ELinks browsers are unusable on
 Debian GNU/Hurd
In-Reply-To: <87zlvxqx3u.fsf_-_@Astalo.kon.iki.fi>
References: <20071213203434.GA7309@gmail.com>
	<87ir2zzoe2.fsf@Astalo.kon.iki.fi> <fk987c$pjp$1@ger.gmane.org>
	<87wsra9ulx.fsf@Astalo.kon.iki.fi> <20071220023812.GA22464@gmail.com>
	<87prx29ef4.fsf@Astalo.kon.iki.fi> <20071220225026.GA9244@gmail.com>
	<87d4t06epl.fsf@Astalo.kon.iki.fi> <fkf6s9$l2a$1@ger.gmane.org>
	<87zlvxqx3u.fsf_-_@Astalo.kon.iki.fi>
Message-ID: <87ve6jy9fs.fsf@Astalo.kon.iki.fi>

Kalle Olavi Niemitalo <kon at iki.fi> writes:

> It seems to me that you Hurd people have three ways to fix this:

Until you have a proper fix, you might also patch ELinks to work
around the bug.  The following patch causes RPCs that are in
principle unnecessary, but perhaps they won't slow things down
too much.  Changing the set_handlers calls to pass NULLs would
be more efficient, but there are a few variables where it is not
trivial to figure out statically whether the file descriptor
refers to a pipe or rather a socket, so I think this way is safer.

If there is a public ID for this bug, I'd like to mention it 
in "Supported platforms" at <http://elinks.cz/about.html>,
and in a comment in set_handlers.

diff --git a/src/main/select.c b/src/main/select.c
index aab5349..382e609 100644
--- a/src/main/select.c
+++ b/src/main/select.c
@@ -10,6 +10,9 @@
 #ifdef HAVE_SYS_SIGNAL_H
 #include <sys/signal.h>
 #endif
+#ifdef __GNU__ /* For GNU Hurd bug workaround in set_handlers */
+#include <sys/stat.h> /* OS/2 needs this after sys/types.h */
+#endif
 #include <sys/types.h>
 #ifdef HAVE_SYS_WAIT_H
 #include <sys/wait.h>
@@ -146,6 +149,19 @@ set_handlers(int fd, select_handler_T read_func, select_handler_T write_func,
 		fd, FD_SETSIZE);
 	if_assert_failed return;
 #endif
+#ifdef __GNU__
+	/* As of 2007-12, GNU/Hurd has a bug: if ELinks does a
+	 * select() where the initial exceptfds set includes a pipe
+	 * that is not listed in the other fd_sets, then select()
+	 * always reports an exception there.  To work around this
+	 * bug, do not monitor exceptions for pipes on the Hurd.  */
+	if (error_func) {
+		struct stat st;
+
+		if (fstat(fd, &st) == 0 && S_ISFIFO(st.st_mode))
+			error_func = NULL;
+	}
+#endif
 	threads[fd].read_func = read_func;
 	threads[fd].write_func = write_func;
 	threads[fd].error_func = error_func;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20071228/cbf773cf/attachment.bin 

From olafBuddenhagen at gmx.net  Fri Dec 21 16:25:48 2007
From: olafBuddenhagen at gmx.net (olafBuddenhagen at gmx.net)
Date: Fri, 21 Dec 2007 23:25:48 -0000
Subject: [elinks-dev] The Links/Links2/ELinks browsers are unusable
	on	Debian GNU/Hurd
In-Reply-To: <20071220225026.GA9244@gmail.com>
References: <20071213203434.GA7309@gmail.com>
	<87ir2zzoe2.fsf@Astalo.kon.iki.fi> <fk987c$pjp$1@ger.gmane.org>
	<87wsra9ulx.fsf@Astalo.kon.iki.fi>
	<20071220023812.GA22464@gmail.com>
	<87prx29ef4.fsf@Astalo.kon.iki.fi>
	<20071220225026.GA9244@gmail.com>
Message-ID: <20071221165911.GA1662@alien.local>

Hi,

On Thu, Dec 20, 2007 at 11:50:26PM +0100, Fabienne Ducroquet wrote:
> On Thu, Dec 20, 2007 at 06:29:51AM +0200, Kalle Olavi Niemitalo wrote:

> > I mean, the compiler might merely have decided to load the
> > address of free_itrm into a register at that point, or something
> > like that.
> 
>     But how could I see that?

Probably only by looking at the assembly code.

> > > As you can see, there is something wrong there,
> > 
> > I don't see that.
> 
>     You are probably more experienced than me in that sort of thing, for
> me that seems at least very weird. :-)

The compiler shuffles instruction when doing strong optimizations, so
they often get executed in a different order then in the source code;
sometimes it's even impossible to tell where exactly some piece of code
came from. Thus gdb jumps around in the source code in a very confusing
manner.

It would really really help if you compile elinks with -O0 or -O1 before
running gdb on it...

>     I tried rpctrace elinks but I don't know what to look for in the
> output...

Yeah, rpctrace output is quite hard to grasp because of the async nature
of things...

> There are lines such as:
> 
> task2573->vm_deallocate (21331968 4096) = 0 
>   88->io_select_request (2)task2573->mach_port_destroy (pn{ 25}) = 0 
> reply(94:io_select_request)->io_select_reply (0 2);
>   72->io_write_request ("^[[1;1H" -1) = 0 6
>   52->io_select_request (5)task2573->mach_port_allocate (3) = 0 pn{ 29}
> task2573->mach_port_move_member (pn{ 25} pn{ 29}) = 0 
>   86->io_select_request (5)task2573->mach_port_move_member (pn{ 27} pn{ 29}) = 0 
>   88->io_select_request (6)task2573->mach_port_move_member (pn{ 28} pn{ 29}) = 0 
> reply(96:io_select_request)->io_select_reply (0 2);
> task2573->mach_port_destroy (pn{ 25}) = 0 
> 
>     What must I look here? ?the numbers between parenthesis after
> io_select_reply (in that case, they are always (0 1) or (0 2) or (0 0))?

Exactly. To find out what they mean, we have to look at the definition
of the io_select RPC in hurd/hurd/io.defs:

   simpleroutine io_select_reply (
	   reply: reply_port_t;
	   RETURN_CODE_ARG;
	   select_result: int);

The reply port is hidden by rpctrace, so we only see two values. I have
no clue what the first one (RETURN_CODE_ARG) means. The second is the
select_result. To make sense of it, you probably need to look at the
select() implementation in the Hurd-specific glibc code.

It might be more useful actually to step through the select()
implementation rather then looking at rpctrace output. This way you can
see with what parameters it is called, what server it invokes, what
results it gets etc.

> > Also try putting the NULLs in ELinks
> > like I mentioned in the previous message.
> 
> Something like the following patch?  It seems to work, but perhaps it
> breaks something else.

Well, at least this way we know that this is indeed the problem. Now it
would be useful to find out whether the Hurd is doing anything wrong
here (POSIX should tell), and if so, try to find out why...

BTW, this issue is most certainly not Debian-specific. It would be
better discussed on bug-hurd at gnu.org -- better chance some clueful
developer will see it...

-antrik-