Return-Path: X-Original-To: rt-comment@krbdev.mit.edu Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by krbdev.mit.edu (Postfix) with ESMTP id 427CFCD08F for ; Tue, 30 Dec 2008 17:02:24 +0000 (UTC) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id mBUH2MUl014581 for ; Tue, 30 Dec 2008 12:02:22 -0500 (EST) Received: from [192.168.1.47] (pool-71-162-89-30.bstnma.east.verizon.net [71.162.89.30]) (authenticated bits=0) (User authenticated as epeisach@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id mBUH2L2W020123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 30 Dec 2008 12:02:22 -0500 (EST) Message-ID: <495A5407.8010000@mit.edu> Date: Tue, 30 Dec 2008 12:01:59 -0500 From: Ezra Peisach User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: rt-comment@krbdev.mit.edu Subject: Re: [krbdev.mit.edu #6308] Alignment problem in resolver test References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-BY: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 RT-Send-Cc: X-RT-Original-Encoding: iso-8859-1 Content-Length: 2763 Great - thanks for the insight... I will try to code around it next week... Ezra Jorgen Wahlsten via RT wrote: > 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 >> >> > > > >