| Title: | Alpha Developer Support |
| Notice: | [email protected], 800-332-4786 |
| Moderator: | HYDRA::SYSTEM |
| Created: | Mon Jun 06 1994 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3722 |
| Total number of notes: | 11359 |
Company Name : Iona Technologies - Point 24910
Contact Name : Aileen Cunningham
Phone : +353 1 6625255
Fax : +353 1 6625244
Email : [email protected]
Date/Time in : 7-APR-1997 09:33:53
Entered by : Ian Chamberlin
SPE center : REO
Category : unix
OS Version : 3.2
System H/W :
Brief Description of Problem:
-----------------------------
From: RDGENG::MRGATE::"RDGMTS::PMDF::mail.dec.com::Santing" 7-APR-1997 07:55:56.83
To: RDGENG::ASAP
CC:
Subj: FW: ESCALATION: POINT 24910, Iona Technologies
From: NAME: Ben Santing <[email protected]@PMDF@INTERNET>
To: NAME: '[email protected]' <IMCEAX400-c=US+3Ba=+20+3Bp=DIGITAL+3Bo=SBUEURMFG+3Bdda+3ASMTP=asap+40reo+2Emts+2Edec+2Ecom+3B@mail.dec.com@PMDF@INTERNET>
Hello -
POINT Log Number 24910
Company Name Iona Technologies
Engineers name Aileen Cunningham
Telephone Number +353 1 6625255
Fax Number +353 1 6625244
E-mail Address [email protected]
Operating System, Version OSF1 V3.2 148
Platform
Problem Statement
I'm having problems using the gethostbyname_r system call on
OSF1 explicit V3.2 148 alpha with version 5.5 of the cxx C++
compiler.
The problem is demonstared by the following sample code.
The first call to gethostbyname_r works correctly but the 2nd call
core dumps.
The program is compiled as follows
cxx -D_REENTRANT -threads -g hst.cc -ohst
and when exectued produces the following output.
./hst
res is 0 errno is 0 h_errno is 0
Segmentation fault (core dumped)
The stack trace at the moment of the crash is
decladebug hst
Welcome to the Ladebug Debugger Version 4.0-14A
------------------
object file name: hst
Reading symbolic information ...done
(ladebug) t
Program hasn't started running
(ladebug) r
res is 0 errno is 0 h_errno is 0
Thread received signal SEGV
stopped at [???: ??? 0x400000800000000]
(ladebug) t
>0 0x400000800000000 in ???
(ladebug)
Regards,
Aileen Cunningham
--------------------------- TEST PROGRAM
--------------------------------------
#include <netdb.h>
#include <iostream.h>
#include <errno.h>
void connect(char *name)
{
struct hostent hptr;
struct hostent_data hdptr;
int res;
memset (&hdptr, 0, sizeof(hdptr));
res = gethostbyname_r (name, &hptr, &hdptr);
cout << "res is " << res << " errno is " << errno << " h_errno is "
<<
h_errno
<< endl;
}
int main()
{
connect("explicit.dublin.iona.ie");
connect("true.dublin.iona.ie");
return 0;
}
Regards,
Ben Santing
In replying, please use [email protected]
RFC-822-headers:
Received: from reoexc1.reo.dec.com by rg71rw.reo.dec.com (PMDF V5.0-7 #15552)
id <[email protected]> for [email protected]; Mon,
07 Apr 1997 07:50:36 +0100
Received: by reoexc1.reo.dec.com with SMTP
(Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
id <[email protected]>; Mon, 07 Apr 1997 07:53:15 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3444.1 | known bug in 3.2x | RDGENG::CHAMBERLIN | Danger! Do not Reverse Polarity | Mon Apr 07 1997 11:38 | 19 |
Aileen, The problem you describe with gethostbyname_r is a known problem with Ditital Unix V3.2x. There is a patch available; I think the Patch Id for Digital Unix V3.2c (which you are using) is OSF350-108, but will be different for other V3.2 versions. You should be able to get this from your local Customer Support Centre, or our www site http://www.service.digital.com, if you have a service contract. I dont believe its available under the public patches tree on our www site. The problem is fixed in Digital Unix V4.0/A/B releases, so we would recommend you upgrade. regards, Ian Chamberlin, Digital Equipment Co, Software Partner Engineering. | |||||
| 3444.2 | Difficulty finding patch | RDGENG::CHAMBERLIN | Danger! Do not Reverse Polarity | Mon Apr 28 1997 10:45 | 11 |
As of 17 April, the partner had difficulty finding the patch, either on http://wis.europe.digital.com:2429, or from the Irish and UK CSC's On checking, I found that patches had been consolidated, so OSF350-108 is now paart of OSF350-279, but surely the CSC could have found this as well? Haven't heard anything since 17 April, so assume partner has the patch, and close the call. | |||||