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.
pgpLaU0I9VpXe.pgp
Description: PGP signature
_______________________________________________ elinks-dev mailing list [email protected] http://linuxfromscratch.org/mailman/listinfo/elinks-dev
