2 Lynx "Bugs".

["Chad Kline"]

1. lynx is unresponsive when doing DNS lookups. this is a problem with lookups that take an endlessly long time for whatever reason, and for some failed connections/negotiations; and CTRL-G can't end the wait and/or lockups. i am using the latest lynx from source and FreeBSD 9.2.

2. it would be nice if lynx would create links for javascript code, so that i don't have to look at the source and create the links myself. many javascript links are functional when manually appending the relative links to the page URL, and lynx should present them instead of pretending that they don't exist.

[Thomas Dickey]

1. lynx is unresponsive when doing DNS lookups. this is a problem with
lookups that take an endlessly long time for whatever reason, and for some
failed connections/negotiations; and CTRL-G can't end the wait and/or
lockups. i am using the latest lynx from source and FreeBSD 9.2.

I've not seen that - but do recall that you can get timeouts in the actual connection.
The connection attempts aren't interruptible with ctrl/G.

2. it would be nice if lynx would create links for javascript code, so that
i don't have to look at the source and create the links myself. many
javascript links are functional when manually appending the relative links to
the page URL, and lynx should present them instead of pretending that they
don't exist.

"should" is relative (patches are welcome)

[Thorsten Glaser]

Post by Thomas Dickey

1. lynx is unresponsive when doing DNS lookups. this is a problem with
lookups that take an endlessly long time for whatever reason, and for some
failed connections/negotiations; and CTRL-G can't end the wait and/or
lockups. i am using the latest lynx from source and FreeBSD 9.2.

I've not seen that

I’m seeing this on BSD all the time, if the resolver cannot
get any response (e.g. if the resolver is DJB dnscache, and
the domain in question hosted at OVH – no big loss there…),
or if the response is slow.

I haven’t seen this on GNU yet. Maybe DNS behaves differently
across systems?

bye,
//mirabilos

[Thomas Dickey]

Post by Thomas Dickey

1. lynx is unresponsive when doing DNS lookups. this is a problem with
lookups that take an endlessly long time for whatever reason, and for some
failed connections/negotiations; and CTRL-G can't end the wait and/or
lockups. i am using the latest lynx from source and FreeBSD 9.2.

I've not seen that

I’m seeing this on BSD all the time, if the resolver cannot
get any response (e.g. if the resolver is DJB dnscache, and
the domain in question hosted at OVH – no big loss there
),
or if the response is slow.
I haven’t seen this on GNU yet. Maybe DNS behaves differently
across systems?

...or else OVH has some problem with DNS?

I could test lynx from one of my local machines, but everything's
going through the same DNS. (Some clues for how I could reproduce
the problem would be helpful).

[Thorsten Glaser]

Post by Thomas Dickey
...or else OVH has some problem with DNS?

Yes, they do, but the problem with Lynx is: when DNS is slow, for
whatever reasons (including, but not limited to, the receiving
server being hosted at OVH), I cannot interrupt Lynx’ DNS lookup
using z or ^G.

bye,
//mirabilos

[Ian Collier]

Post by Thomas Dickey
I could test lynx from one of my local machines, but everything's
going through the same DNS. (Some clues for how I could reproduce
the problem would be helpful).

How about: edit resolv.conf and put a non-existent server (e.g. 10.0.0.1)
as the first nameserver. In my experience this adds a delay of 7-10
seconds during which Lynx can't be interrupted with z or ^G. However,
^C does interrupt it (and exits Lynx).

imc

[Thomas Dickey]

Post by Ian Collier

Post by Thomas Dickey
I could test lynx from one of my local machines, but everything's
going through the same DNS. (Some clues for how I could reproduce
the problem would be helpful).

How about: edit resolv.conf and put a non-existent server (e.g. 10.0.0.1)
as the first nameserver. In my experience this adds a delay of 7-10
seconds during which Lynx can't be interrupted with z or ^G. However,
^C does interrupt it (and exits Lynx).

That still doesn't get me there: lynx is behaving as I would expect.
Tested with both Debian 6 and FreeBSD 9.1

However, it occurs to me that one or more of the people on this thread
overlooked the fact that the NSL-fork feature (which provides the
interruptibility) has "always"(*) been not compiled-in by default:

--enable-nsl-fork (define NSL_FORK)
Disabled by default, this allows interruption of NSL requests,
so that `z' will stop the `look-up' phase of a connection.

If it's compiled-in, then NSL_FORK will show up in the "lynxcompileopts:"
special page.

_After_ resolving DNS, there is as I pointed out, still a possible timeout
connecting to the actual page. That's not interruptible, as I recall it.
Once _connected_, the process of downloading is interruptible - by polling
between reads from the source.

The last time I worked on this aspect of the code was in 2012, to fix the
problem where sites with multiple IP-addresses did not all succeed (due to
limited number of addresses passed back from the forked process). Problems
in this might show up in the -trace file - however, the trace file doesn't
really show what's going on in the forked process. A truss (with timestamps)
could show that.

On the other hand, it might be just a configuration problem as I suggested :-)

(*) since I added the configure option late in 1997

[Thorsten Glaser]

Post by Thomas Dickey
If it's compiled-in, then NSL_FORK will show up in the "lynxcompileopts:"
special page.

This shows

NSL_FORK 1

for me. IIRC, enabling this solved a similar problem back in
the days, but not all of it.

bye,
//mirabilos

PS: FreeBSD is not representative for BSD.

[Thomas Dickey]

Post by Thorsten Glaser

Post by Thomas Dickey
If it's compiled-in, then NSL_FORK will show up in the "lynxcompileopts:"
special page.

This shows
NSL_FORK 1
for me. IIRC, enabling this solved a similar problem back in
the days, but not all of it.
bye,
//mirabilos
PS: FreeBSD is not representative for BSD.

that's debatable, of course. I have a MirBSD on my older server, and OpenBSD
5.3 on the newer one (the newer one, of course is what I'm usually running...).

A config.status from building the copy that you're having problems with
would tell me most of what I'd need to duplicate the configuration.