Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-RT-Original-Encoding: iso-8859-1 Content-Length: 2695 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