From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2220 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Difference between -O2 and -g Date: Fri, 26 Oct 2012 13:58:49 -0400 Message-ID: <20121026175849.GZ254@brightrain.aerifal.cx> References: <20121026014022.GT254@brightrain.aerifal.cx> <20121026023254.GU254@brightrain.aerifal.cx> <20121026025545.GV254@brightrain.aerifal.cx> <20121026031906.GW254@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1351274338 19749 80.91.229.3 (26 Oct 2012 17:58:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Oct 2012 17:58:58 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2221-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 26 19:59:07 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TRoBX-00084j-GY for gllmg-musl@plane.gmane.org; Fri, 26 Oct 2012 19:59:07 +0200 Original-Received: (qmail 19977 invoked by uid 550); 26 Oct 2012 17:58:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 19967 invoked from network); 26 Oct 2012 17:58:59 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2220 Archived-At: On Fri, Oct 26, 2012 at 02:44:36PM +0800, Brian Wang wrote: > >> The failed call is within dix/colormap.c:CreateColormap(). > >> > >> Thanks for helping. I really appreciate it. > > > > I would check out Xext/security.c SecurityResource() and see if you > > can figure out what it's doing. That appears to be the callback that's > > getting called. You might want to check and see if there are any > > others that could be registered; this could be done by grepping for > > XaceRegister.*RESOURCE, which I didn't do because I'm browsing the > > source online and the web interface seems to lack grep. > > > > With a bit of digging, I found the source code of this oldish xserver > may trigger an undefined behaviour. > When calling XaceHook(int hook, ...), the switch case looks like this: > --------- > switch (hook) > { > case XACE_RESOURCE_ACCESS: { > XaceResourceAccessRec rec = { > va_arg(ap, ClientPtr), > va_arg(ap, XID), > va_arg(ap, RESTYPE), > va_arg(ap, pointer), > va_arg(ap, RESTYPE), > va_arg(ap, pointer), > va_arg(ap, Mask), > Success /* default allow */ > }; > calldata = &rec; > prv = &rec.status; > break; > } > --------- > I think gcc-4.7.2 looks at 'rec' and thinks it is local to the switch > case and optimizes it away. However, 'prv' will be accessed > down below outside the case. > I do not know whose fault this is (most likely this piece of code), > but certainly not musl's. :-) Nice catch. This is definitely a case of invoking undefined behavior. Actually, gcc should have issued a big warning about this (letting a pointer to an automatic object escape its lifetime); I'm surprised it didn't. Unfortunately I was looking at the current version of the code which does not have this bug. Rich