1. The problem is reproducible under Solaris10/SPARC
2. The problem takes places not only at DNSServiceResolve() -- once we
reproduced that error with DNSServiceQueryRecord().
3. If I call the failed function (e.g. DNSServiceResolve()) right after its
return once again, it works. So, I enclosed all calls to libraries functions
with loops with few iterations, calling the library function again if it
fails, and.. the problem has "gone" -- I mean, even though sometimes a call
fails, but due to next successful attempts it is no longer noticeable from
the application level.
4. I have to make the following change to mDNSResponder sources:
In my opinion, it is a bug that deliver_request() doesn't return error code
if it can't write to socket. In case of SIGPIE, application can disable that
signal or ignore it, thus, allowing the guilty code (that raised SIGPIPE) to
continue. Without the change above, deliver_request() returns with a
successful return code.
I would also consider different types of errors which can take place because
of failed writing to socket, and assign different error codes, not just
kDNSServiceErr_Unknown.
5. It is still not clear who closes the socket, so, the reason why SIGPIPE
takes place is still unknown.
----- Original Message -----
From: "Igor Seleznev" <email@hidden>
To: <email@hidden>
Sent: Friday, January 19, 2007 1:54 PM
Subject: DNSServiceResolve() fails with -65537 under Solaris 10
Hi,
We are using mDNSResponder v107.6 quite extensively for half a year
already, under Red Hat Linux/AMD and Solaris 10/AMD, both mdnsd and
libdns_sd.so 64-bit.
And we experience a floating problem, under Solaris10 only: sSometimes,
DNSServiceResolve() fails with -65537 error code due to SIGPIPE happend
within. SIGPIPE is caught at this place:
If we take into consideration the facts that:
1) it works in 99.9% of cases and the problem is reproducible quite rarely
2) it never happens under Red Hat Linux
3) it takes place with DNSServiceResolve() only and always ends up with
SIGPIPE and -65537 error code
4) no errors in /var/adm/messages from mdnsd
5) mdnsd is functioning with no noticeable problems
....the question is: what can cause this?
Does anyone experience such problem?
Do you know how to trace down the closer of the socket?
Perhaps we are just lucky and catch problems with DNSServiceResolve() only
while it probably reproducible with other functions too -- if it happens
I'll immediately let you know.
Can we say/assume that getting SIGPIPE is a "normal" situation which
application should take care of, or this should never happen at all?
As far as I understand some platforms do not allow you to configure a
socket (via setsockopt()) so that it doesn't throw SIGPIPE on "writing to
closed socket" but returns EPIPE error instead, therefore, there seem not
sense in such socket configuring at all and we should receive SIGPIPE
quite often. But, in fact it doesn't happen at all, except in this case...
Any help is very appreciated!
Kind regards,
Igor
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bonjour-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/bonjour-dev/email@hidden
