153567 - Delayed startup if no DNS

Status: RESOLVED WORKSFORME

(Camino Graveyard :: General, defect)

Description

[Stephane Moureau]

Build 20020621 16:08
If your ISP has a DNS problem, Chimera takes several seconds to get opened, even
with a blank page, no default home.
I'm on iMac 400Mhz with AirPort to Snow AirBase, that's why IP is 10.0.1.1.
It opens immediately if Airport is desactivated.

Jun 21 14:06:57 localhost lookupd[224]: DNSAgent: dns_send_query_server -
timeout for 10.0.1.1

Jun 21 14:06:59 localhost last message repeated 2 times

Jun 21 14:06:59 localhost lookupd[224]: DNSAgent: dns_fqdn_query_server - query
failed for 10.0.1.1

Comment 1

[saari (gone)]

we need to fix this, is the timeout set by a pref?

Comment 2

[Mike Pinkerton (not reading bugmail)]

the question is why we're stalling even with about:blank.

--> bryner

Comment 3

[Brian Ryner (not reading)]

We're stalling because we need to look up the local hostname in order to create
the profile lock file.  If we can't find a way to do that without a DNS lookup,
a potential workaround would be to use the Mac (Carbon) profile locking code
instead of the Unix code.

Comment 4

[Conrad Carlen (not reading bugmail)]

Better than using the Carbon locking code, use the 2nd attempt method for Unix.
This code:
http://lxr.mozilla.org/mozilla/source/profile/src/nsProfileAccess.cpp#1959. I
think the failsafeness of that method outweighs the chance of F_SETLK not being
supported on a server somebody would use Chimera with. The F_SETLK code is
better than the Carbon code, anyway.

Comment 5

[Brian Ryner (not reading)]

Ok, so we have a few possibilities.  I hacked up a way to grab the local IP
address without doing a DNS lookup; we may want to do this anyway if it will
help startup time.  I'll attach that patch.

Comment 6

[Brian Ryner (not reading)]

Attachment: use a dummy socket connection to grab the host address

Comment 7

[Brian Ryner (not reading)]

Attachment: patch #2

Oops, I reversed the memcmp() comparison.

Comment 8

[Brian Ryner (not reading)]

Attachment: patch #3

Ok, third time's a charm, hopefully.  I was neglecting the fact that the port
numbers would be different in the two structs even if the addresses match, so I
changed it to only compare the address field.  Tested with both the local and
remote lock cases and this seems to work correctly.

Comment 9

[Brendan Eich [:brendan]]

Wouldn't it be better to use gethostid(2)?  Or some socket ioctl way to get the
primary interface's configured IP address, if any is available?

/be

Comment 10

[Brian Ryner (not reading)]

gethostid does not return the IP address on all platforms.  glibc intentionally
switches the low and high 16 bits of the address to make it _not_ be the IP address.

Comment 11

[Wan-Teh Chang]

Comment on attachment 89243 [details] [diff] [review]
patch #3

Getting the IP address of the local host is
rather tricky and I don't know of a way that
works on all platforms.

The correct way to do that on Unix is to use
either the SIOCGIFCONF ioctl or the NET_RT_IFLIST
sysctl.  There is sample code in BSD's getifaddrs.c
and Richard Stevens' Unix Network Programming,
Vol. 1, 2nd. Ed., Sections 16.6 and 17.5.

You should explain why this code will work if
www.mozilla.org has a different IP address than
the hardcoded 207.200.81.215.

On a machine with multiple IP addresses, are you
sure that this code will return the same IP
address?

Make sure you test this code on all the platforms
that this code needs to run on.

Comment 12

[Brian Ryner (not reading)]

It's not important what remote IP address is used.  Since it is a UDP socket,
calling connect() does not actually send any data.  It does, however, enable you
to obtain the local IP address for the socket.

On a machine with multiple IP addresses, this will [unless a specific route has
been configured] return the IP address with the default route assigned to it.  I
believe that's what we want here.

All of the documentation I've found on sysctl() and ioctl() lead me to believe
that it's rather nonportable.  Is that the case?

Comment 13

[Sean Harding]

This is effecting me on FreeBSD, so Platform Mac isn't accurate.

Comment 14

[Stephane Moureau]

Seems to be solved since several builds, today build is 1204.
I disable Airport and seems to launch with no time difference when Airport is on
(and internet of course).

Comment 15

[Jasper]

WFM using 2004100808 (v0.8+) NB on 10.3.5.

I have tested on my iBook and eMac and neither of them have any difference in
weither I start Camino when internet is enabled of disabled. I also haven't seen
anybody seeing this bug in a long while.

Please reopen if necesarry with an update.