topic Re: gethostbyname dumps with SIGSEGV in Operating System - Linux

gethostbyname dumps with SIGSEGV

David Malkson — Tue, 04 Dec 2007 19:53:13 GMT

I'm porting an application from Linux to Solaris, and now HP-UX.

The HP-UX port gets SIGSEGV in gethostbyname the second time the function containing it is called.

I'm compiling -Aa -D_HPUX_SOURCE -D_POSIX_SOURCE, linking dynamically, and the program is not threaded.

Any clues where to look?

Re: gethostbyname dumps with SIGSEGV

James R. Ferguson — Tue, 04 Dec 2007 20:02:38 GMT

Hi:

Verify your arrays are sized correctly and that your pointers are valid.

Regards!

...JRF...

Re: gethostbyname dumps with SIGSEGV

A. Clay Stephenson — Tue, 04 Dec 2007 20:13:10 GMT

Can I assume that you are first testing to see if a NULL pointer is returned before referencing any fields within the struct? If not, that would certainly trigger a SIGSEGV.

Re: gethostbyname dumps with SIGSEGV

Sandman! — Tue, 04 Dec 2007 21:03:15 GMT

If it's not too big post the code here so we can take the guesswork out of it.

Re: gethostbyname dumps with SIGSEGV

David Malkson — Tue, 04 Dec 2007 21:38:51 GMT

OK, here's the source:

static
int resolv_hostname( const char *hname,struct sockaddr_in *sin ){
struct hostent *hostp = NULL;
unsigned long addr;

addr = inet_addr( hname );
if (addr != (in_addr_t)-1)
memcpy( &sin->sin_addr, &addr, sizeof( addr ));
else {
hostp = gethostbyname( hname );
if( hostp == NULL )
return -1;
else
memcpy( &sin->sin_addr, hostp->h_addr_list[0], hostp->h_length );
}
return 0;
}

It SIGSEGV's in the gethostbyname call.

The WDB stack says:

strlen+0xc
+ 0x64
+ 0x108
nss_search+0x114
__getghostbyname+0x140
gethostbyname+0x94

all from /usr/lib/libc.2

The hname variable is valid and contains a valid hostname string.

Copying the hname value to a big temporary buffer string makes no difference.

Re: gethostbyname dumps with SIGSEGV

Sandman! — Tue, 04 Dec 2007 22:17:20 GMT

Some things that you may want to look at. The argument types do not agree with the prototypes of most functions you are using:

change... unsigned long addr;
to... struct in_addr addr;

if ((addr = inet_addr(hname)) == -1)
...

Re: gethostbyname dumps with SIGSEGV

David Malkson — Tue, 04 Dec 2007 23:18:33 GMT

According to the man page, that should be in_addr_t, not a struct.

I changed it to in_addr_t and it made no difference.

FWIW, the Linux and Solaris ports run just fine and according to all the tools the other OS's have no memory issues.

That leads me to think it is some some include, define, compile switch, or library issue with the HP-UX port.

Re: gethostbyname dumps with SIGSEGV

Sandman! — Wed, 05 Dec 2007 03:53:57 GMT

Since your program is pretty short why don't you post the entire code along with the list of include'd header files and the command you are using for compiling.

~thanks

Re: gethostbyname dumps with SIGSEGV

Sandman! — Wed, 05 Dec 2007 04:12:31 GMT

Ooops hit the submit button prematurely. Trying to clear confusion caused by...

> if ((addr = inet_addr(hname)) == -1)

when I meant...

if ((addr.s_addr = inet_addr(hname)) == -1)

where s_addr is a member of the in_addr structure and is of type in_addr_t.

Re: gethostbyname dumps with SIGSEGV

Dennis Handly — Wed, 05 Dec 2007 04:23:49 GMT

>According to the man page, that should be in_addr_t, not a struct.

Right.
I had to use in_addr_t so it would work in 64 bit mode.

Re: gethostbyname dumps with SIGSEGV

Dennis Handly — Thu, 06 Dec 2007 09:16:18 GMT

I assume this is the same as the issue reported in comp.sys.hp.hpux under "gethostbyname core dumps"?

Someone mentioned that h_length in memcpy wasn't valid:
memcpy(&sin->sin_addr, hostp->h_addr_list[0], hostp->h_length);

From the man page, I have no idea whether h_length is the size of h_addr_list[0] or of all of them.

Best to use sizeof(sin->sin_addr).

Re: gethostbyname dumps with SIGSEGV

David Malkson — Sat, 08 Dec 2007 17:49:38 GMT

Yes, this is the same problem as the USENET posting.

This frament is a small part of a huge program.

WDB doesn't complain about any memory issues, but I just installed the latest SunStudio 12 and ran the Solaris version under it where memory issues are reported elsewhere.

The strange thing is WDB says it's OK and it dumps in the middle of a libc call that has a valid string as a parameter.

At this point the only conclusion I can come to is that the HP implementation of gethostbyname has some area that is reused between calls which is getting hosed.

Re: gethostbyname dumps with SIGSEGV

Dennis Handly — Sat, 08 Dec 2007 22:55:55 GMT

>This fragment is a small part of a huge program.

That's why several people and I can't duplicate the abort. Have you linked with -z to catch NULL pointer dereferences?

>WDB doesn't complain about any memory issues

You're using "set heap-check on"?

>The strange thing is WDB says it's OK and it dumps in the middle of a libc call that has a valid string as a parameter.

WDB is only checking the heap usage, not everything. (It relies on the hardware to check the rest. :-)

>At this point the only conclusion I can come to is that the HP implementation of gethostbyname has some area that is reused between calls which is getting hosed.

Possibly.
Are you up to date on patches?

>the second time the function containing it is called.

Are you passing the same string the second time?

Re: gethostbyname dumps with SIGSEGV

David Malkson — Mon, 10 Dec 2007 20:51:12 GMT

I added a bunch of syslog() calls to the code, now it core dumps in syslog and the stack shows

malloc
malloc_padded
malloc
localtime_r
ctime_r
syslog

I ran a patch assessment and installed the latest patches last week

WDB 5.7 has all memory checks enabled.

CFLAGS = -Ae +w1 +ESnolit -z -g

LIBS = -lxnet -lrtc

This works flawlessly on Solaris.

I'm back to guessing it is a library compatibility issue as it has always dumped in libc.2.

I guess I could put the whole thing up on an anonymous CVS server if noone has any other hints without full sources.

Re: gethostbyname dumps with SIGSEGV

Dennis Handly — Mon, 10 Dec 2007 23:07:06 GMT

>now it core dumps in syslog and the stack shows

malloc
malloc_padded
malloc

>WDB 5.7 has all memory checks enabled.

This shows the heap has been corrupted. I'm surprised gdb didn't catch it.

>CFLAGS = -Ae +w1 +ESnolit -z -g

Why are you using +ESnolit? You should use the default or +ESlit.

>I guess I could put the whole thing up on an anonymous CVS server if no one has any other hints without full sources.

I could just try the binary, if you make that available.