[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [elinks-dev] The Links/Links2/ELinks browsers are unusable on Debian GNU/Hurd

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:


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: pgpnclfYR2uBg.pgp
Description: PGP signature

Reply to: