Hello Ezra.

Yes, I used a 32-bit compiled gcc 4.1.1.

I do not have Sun's C compiler and can not verify that it is working with it, but if it's important for you to verify that it is working with Sun's C compiler, I can try to get it. Let me know.

If I turn on optimization (-O2 or -O3) the program works, while using -O0/-O1 the program still core dumps.

Compiling resolve.c as a 32-bit binary or a 64-bit binary does not seem to matter. It core dumps no matter what.

I was thinking this had something to do with automatic variable alignment, and therefore changed:

char myname[MAXHOSTNAMELEN+1]

to

char myname[MAXHOSTNAMELEN+8]

(MAXHOSTNAMELEN is defined as 256 in netdb.h),

which makes the program work again (not core dump).

For what it's worth, I think Sun's C compiler *always* aligns the automatic variables on 8-byte boundaries, while GCC tries to fit the addrcopy[4] into the "padding" of myname[256+1] (7 bytes padding?), as an optimization. It does seem strange that this is done *without* optimization though.

Regardless, of the differences between Sun's C compiler and GCC, I would be inclined to agree with you that this is a solaris C library bug, that is being triggered by using GCC in this particular case.

As for my comment about using an in_addr pointer, I think I merely looked at the EXAMPLE section in the solaris 2.10 gethostbyaddr man page. There is also a NOTE in that man page about INET_ADDR.

Let me know if you want to any additional information.

Thanks,
Jorgen




On Sat, Dec 27, 2008 at 3:17 PM, Ezra Peisach via RT <rt-comment@krbdev.mit.edu> wrote:
Okay - I have been able to reproduce the problem on one MIT's solaris
machines - but only when using gcc....

This is gcc version 3.4.3 on a machine running  Solaris 10 3/05
s10_74L2a SPARC.

I modified the code to allow me to vary the alignment of the memory.
Sure enough, gethostbyaddr segfaults in the nss library.

Now - why is this only w/ gcc and not sunsoft's compiler - I could not
tell you.

Looking at the opensolaris library source for libnss - I do see that
there is a path where the pointer to the char * is assigned a struct
in_addr *.

See IN6_INADDR_TO_V4MAPPED macro in /usr/include/netinet/in.h.

The error does not appear to be an optimization issue...

Now - why is gcc screwing up? I will need to investigate... I will have
to look at the assembly code to see what is going on....

So - can you please confirm that your problem is observed w/ gcc?
Ezra



--
_______________________________________________________________________
Jorgen Wahlsten -- http://www.wahlsten.com/
AIM: JorgenWahlsten
YIM: jorgenwahlsten
ICQ: 171198501