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

Kalle Olavi Niemitalo <[email protected]>
Newsgroups gmane.linux.debian.ports.hurd,gmane.comp.web.links
Message-ID <[email protected]>
Fabienne Ducroquet <[email protected]> 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.
signature.asc (application/pgp-signature, 188 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHae/FHm9IGt60eMgRAl6XAJ9v06lcMg5BW3kOmtEhUq3M2SHhtQCcDV9B
ahY1AX7SGcP71Lp99BnvzVs=
=gVt/
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.