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

Fabienne Ducroquet <[email protected]> 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.

_______________________________________________
elinks-dev mailing list
[email protected]
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHaxESHm9IGt60eMgRAnkHAJ0SMjozS3HClVIX3FTTluofCciVygCfft7i
SSYyJkkVDEx3gWZu3BU+js4=
=9CLJ
-----END PGP SIGNATURE-----