[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121026031906.GW254@brightrain.aerifal.cx>
Date: Thu, 25 Oct 2012 23:19:06 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Difference between -O2 and -g
On Fri, Oct 26, 2012 at 11:01:47AM +0800, Brian Wang wrote:
> On Fri, Oct 26, 2012 at 10:55 AM, Rich Felker <dalias@...ifal.cx> wrote:
> > On Fri, Oct 26, 2012 at 10:47:57AM +0800, Brian Wang wrote:
> >> On Fri, Oct 26, 2012 at 10:32 AM, Rich Felker <dalias@...ifal.cx> wrote:
> >> > On Fri, Oct 26, 2012 at 10:04:46AM +0800, Brian Wang wrote:
> >> >> > One very simple way to get a picture of what's going on in a program
> >> >> > is to run it under strace. Try saving strace logs for both the working
> >> >> > version and the broken version and comparing them either manually or
> >> >> > with the diff utility (although the latter may be difficult unless you
> >> >> > filter out the addresses and other contnets that will naturally
> >> >> > differ, so it might be easier to visually inspect). If you don't
> >> >> > already have an strace built for your target, I think Aboriginal Linux
> >> >> > has static binaries you can use.
> >> >>
> >> >> I have previously built my static strace.
> >> >> I could not decipher what went wrong. Please find the strace logs for
> >> >> the three binaries in question.
> >> >> The source code is basically the same, except for the musl ones,
> >> >> printf calls are sprinkled here and there
> >> >> as my desperate attempt.
> >> >
> >> > The good and bad traces diverge at this line, which only happens in
> >> > the good one:
> >> >
> >> > writev(2, [{"CreateColormap : good end\n", 26}, {NULL, 0}], 2) = 26
> >> >
> >> > So search the source for that string and see what condition is causing
> >> > that code to be reached or not reached.
> >>
> >> Thank you for reading through them. :-)
> >>
> >> The failed call (XaceHook) is:
> >> -----------
> >> /*
> >> * Security creation/labeling check
> >> */
> >> i = XaceHook(XACE_RESOURCE_ACCESS, clients[client], mid, RT_COLORMAP,
> >> pmap, RT_NONE, NULL, DixCreateAccess);
> >> if (i != Success) {
> >> fprintf(stderr, "%s : 9\n", __func__);
> >> FreeResource(mid, RT_NONE);
> >> return i;
> >> }
> >> -----------
> >
> > It would help a lot if I knew what source you were using, or at least
> > the part of the tree it corresponds to in the upstrea/latest X source
> > tree, so I could take a look at it.
>
> I am using a mildly patched one based on:
> http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.5.1.tar.bz2
> The patch is about displaying a background ppm image and should be
> after the error path.
>
> 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.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
