Fabienne Ducroquet <fabiduc@gmail.com> writes:
> Did you receive all my replies?
I didn't, but I saw them in debian-hurd archives.
> 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.
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.
> As you can see, there is something wrong there,
I don't see that.
> 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:
That patch forces a call to register_bottom_half(free_itrm, itrm).
However, in your Hurd backtrace, free_itrm was called from line
305 of select.c:
threads[i].error_func(threads[i].data);
This shows the pointer came via set_handlers rather than via
register_bottom_half. So the patch doesn't reveal anything.
Instead, you should find out why the select function is reporting
an exceptional state for the file descriptor.
In my previous message, I claimed that this would be the fault
of the term translator. However, I now realize that you had
mentioned i = 7, which was the itrm->out.sock pipe rather than
the tty. So the problem seems more likely to be with pflocal...
except S_io_select in hurd/pflocal/io.c does
*select_type &= SELECT_READ | SELECT_WRITE;
right away.
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. Also try putting the NULLs in ELinks
like I mentioned in the previous message.
Attachment:
pgp0W_ED9eg7u.pgp
Description: PGP signature