Hi,
Thanks for debugging this! Forwarding it to the appropriate list.
-antrik-
----- Forwarded message from Kalle Olavi Niemitalo <[EMAIL PROTECTED]> -----
Date: Wed, 26 Dec 2007 17:44:37 +0200
From: Kalle Olavi Niemitalo <[EMAIL PROTECTED]>
Subject: Re: [elinks-dev] The Links/Links2/ELinks browsers are unusable on
Debian GNU/Hurd
To: [EMAIL PROTECTED]
Cc: ELinks text WWW browser development mailing list <[EMAIL PROTECTED]>
After some peeking around with QEMU and GDB, I think I have found
the bug. rpctrace shows:
90->io_select_request (5)task7590->mach_port_allocate (3) = 0 pn{ 28}
task7590->mach_port_move_member (pn{ 24} pn{ 28}) = 0
114->io_select_request (5)task7590->mach_port_move_member (pn{ 29} pn{
28})reply(131:io_select_request)->io_select_reply (0 1);
reply? 122 > 0
117->io_select_request (4)task7590->mach_port_move_member (pn{ 27} pn{
28})reply(131:io_select_request)->io_select_reply (0 0);
reply? 122 > 0
_hurd_select in glibc considers the io_select_reply (0 0) a
"bogus answer": if the pipe is not ready for any I/O, then it
should not have responded yet. And so, glibc substitutes
SELECT_ALL, which includes SELECT_URG and triggers free_itrm in
ELinks.
Why did pflocal send the bogus answer, then? When *select_type
is initially SELECT_URG without other flags, S_io_select in
hurd/pflocal/io.c first resets *select_type to zero and then
calls pipe_pair_select in hurd/libpipe/pipe.c. That notices
*select_type is neither SELECT_READ nor SELECT_WRITE, and
apparently assumes it is SELECT_READ | SELECT_WRITE and waits for
either condition. One of the conditions is satisfied, but
*select_type remains zero, and S_io_select then propagates the
zero to the io_select_response.
It seems to me that you Hurd people have three ways to fix this:
(a) Change _hurd_select to completely ignore responses that
have select_type=0. Don't even set SELECT_RETURNED.
This would make the timeout more complex to implement.
(b) Change pflocal to detect when io_select_request is asking
solely for events that cannot ever occur, and sleep until
the caller closes the reply port. Similar changes may be
needed in other servers.
(c) As in (b) but instead of sleeping, just discard the send-once
right without sending any response, and return the thread to
more productive use. I don't know how difficult that would
be with mig.
----- End forwarded message -----
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
