Hello, i am trying to startssl on Sun-sparc Solaris 9 machine with Apache2.0.48 It gives the follwing error. [Tue Mar 09 19:40:37 2004] [crit] [Tue Mar 09 19:40:37 2004] file vhost.c, line 232, assertion "rv == APR_SUCCESS" failed Abort - core dumped it works fine with "start" option. i have installed the Sun recommened Patch cluster. Can u suggest something. Regards, Dheerajk.
Just to verify that we know which getaddrinfo call is failing, please try the test program gawild.c, which I'll attach in a sec. It *should* run like this: [trawick@sol9 platform_test]$ gcc -Wall -o gawild gawild.c -lsocket -lnsl [trawick@sol9 platform_test]$ ./gawild it worked [trawick@sol9 platform_test]$
Created attachment 10713 [details] getaddrinfo(255.255.255.255)
Please re-open bug when you get a chance to try attached program on the Solaris box with the problem and report the results. Thanks!
I have the same problem on Solaris 9, httpd 2.0.49. I tried the program and the output is: getaddrinfo->1 Any clue?
I've run the tool on two sun sparc systems with different results. fwa$ ~/gawild it worked fwa$ uname -a SunOS fwa 5.8 Generic_108528-23 sun4u sparc SUNW,Sun-Fire-480R tii$ ~/gawild getaddrinfo->1 fwa$ uname -a SunOS tii 5.8 Generic_108528-23 sun4u sparc SUNW,Sun-Fire-V210 I wouldn't expect it'd be a hardware issue. As expected, apache runs fine on one of them but not the other.
In a different PR, it was suggested that it can fail when DNS is disabled but work otherwise. Is that possibly the case, or is there a difference in DNS search order between the two machines? I think we need to change APR to deal with this consistently.
I can't find that PR now, but yes, this is reproducible when /etc/nsswitch.conf has "hosts: files" not the normal "hosts: files dns".
(In reply to comment #0) > Hello, > i am trying to startssl on Sun-sparc Solaris 9 machine with Apache2.0.48 > It gives the follwing error. > > [Tue Mar 09 19:40:37 2004] [crit] [Tue Mar 09 19:40:37 2004] file vhost.c, line > 232, assertion "rv == APR_SUCCESS" failed > Abort - core dumped > > it works fine with "start" option. > i have installed the Sun recommened Patch cluster. > > Can u suggest something. > > Regards, > Dheerajk. (In reply to comment #7) > I can't find that PR now, but yes, this is reproducible when /etc/nsswitch.conf > has "hosts: files" not the normal "hosts: files dns". I verified that it also fails when: hosts: nis [NOTFOUND=return] files It fails with: hosts: files nis [NOTFOUND=return] files It works with: hosts: files dns nis [NOTFOUND=return] files
Someone marked this as fixed; this case should at least be handled gracefully without an abort() so it's not really fixed.
This is a very annoying and unintuitive situation. We are using mod_ssl with Apache 2.0.52 in Solaris 9/x86 and as we turned on the SSL it just occured and started dumping core. We also turned off the ServerName directive hoping that it will make it go away but still continued. Need some graceful error message at the least.
*** Bug 21682 has been marked as a duplicate of this bug. ***
*** Bug 28537 has been marked as a duplicate of this bug. ***
This happens when the VirtualHost entry contains _default_. If I change it to an actual IP it works!
*** Bug 35646 has been marked as a duplicate of this bug. ***
*** Bug 36650 has been marked as a duplicate of this bug. ***
In 2.1.x the assert()s in vhost.c now fail gracefully with a configuration error for cases where the system resolver is not configured properly. Probably not worth a backport to 2.0.x since it's just an error case and relatively rare.
*** Bug 30901 has been marked as a duplicate of this bug. ***
Regardsing this issue we find that if we change _default_ in the virtualhostsetion of http.conf to an IP Address this issue does not happen. Where does _default_ get it's address from (dns? etx/hosts?) ??
On our server when we change _default_ to an IP Address it no longer core dumps, where does _default_ get populated from?
This bug is indeed caused by a Solaris bug, namely by http://bugs.opensolaris.org/view_bug.do?bug_id=4944187 which causes the getaddrinfo("255.255.255.255",...) to fail. Bug 4944187 is scheduled to be fixed in the following forthcoming Solaris 10 patches: 125553-03 SunOS 5.10: libnsl and nfsmapid patch 125554-03 SunOS 5.10_x86: libnsl and nfsmapid patch These two patches still have to pass the patch test cycle.
Even if the behaviour of Solaris getaddrinfo must be considered faulty, apache could easily account for this misbehaviour, since the function find_adresses comes in two versions in srclib/apr/network_io/unix/sockaddr.c, the first calling call_resolver and, from there, getaddrinfo; the second treating addresses 0.0.0.0 and 255.255.255.255 specially and otherwise calling gethostbyname or gethostbyname_r. Thus, there is an simply way to fix this: in srclib/apr/configure, change the test address for getaddrinfo (line numbers for httpd-2.2.8): @@ -46266,7 +46266,7 @@ memset(&hints, 0, sizeof(hints)); hints.ai_family = AF_UNSPEC; hints.ai_socktype = SOCK_STREAM; - error = getaddrinfo("127.0.0.1", NULL, &hints, &ai); + error = getaddrinfo("255.255.255.255", NULL, &hints, &ai); if (error) { exit(1); } Then the test would fail in faulty Solaris and the second version of find_adresses be used.