All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Seebach <peter.seebach@windriver.com>
To: "Xu, Dongxiao" <dongxiao.xu@intel.com>
Cc: yocto@yoctoproject.org
Subject: Re: pseudo interaction issue
Date: Fri, 23 Mar 2012 02:16:35 -0500	[thread overview]
Message-ID: <20120323021635.5b4fc048@wrlaptop> (raw)
In-Reply-To: <1332472886.1765.1.camel@dongxiao-osel>

On Fri, 23 Mar 2012 11:21:26 +0800
"Xu, Dongxiao" <dongxiao.xu@intel.com> wrote:

> What do you mean by first build? Did you click "Just bake" button?

Yes.  The original reproducer I saw said that it worked the first time,
but failed the second time.

> 1) build_target(packages)
> 2) build_target(image)
 
> I noticed the pseudo error will happen when calling
> build_target(image). Therefore I also treated it as second build.

Interesting.

I am, currently, sort of stumped on this.  The failures are coming from
the git log/git branch commands using os.popen(), and those calls
appear to be happening in a process:
1.  Which did not have the pseudo library loaded, at all.
2.  Which has LD_PRELOAD set to include pseudo.
3.  Which has most of the PSEUDO_BINDIR, etc., values set.
4.  Which does not have PSEUDO_PREFIX set.

I can't figure out how to get there.  I can't reproduce this outside of
hob, yet.  And obviously, if the pseudo library isn't loaded, I can't
add more debugging or logging to pseudo to fix it.  (I infer that it's
not loaded because os.popen() isn't hitting diagnostic messages in
pseudo's new popen() wrapper, even if they're completely unconditional.)

I added an abort(), and got a core file.  The core file shows a
backtrace in /bin/sh:

#0  0x00007f1232cd8a75 in raise () from /lib/libc.so.6
#1  0x00007f1232cdc5c0 in abort () from /lib/libc.so.6
#2  0x00007f1233497489 in pseudo_get_prefix (pathname=0x7f123349ac9d
"<null>")
    at pseudo_util.c:1060
#3  0x00007f1233498244 in pseudo_setupenv () at pseudo_util.c:717
#4  0x00007f12334955dd in wrap_fork () at ports/common/guts/fork.c:14
#5  0x00007f1233495675 in fork () at ports/common/pseudo_wrappers.c:322
#6  0x000000000044339c in make_child ()
#7  0x0000000000436f04 in ?? ()
#8  0x0000000000433fa4 in execute_command_internal ()
#9  0x000000000043475e in execute_command_internal ()
#10 0x000000000047262a in parse_and_execute ()
#11 0x000000000041fd04 in ?? ()
#12 0x0000000000420e01 in main ()

I haven't found an obvious way to look at the arguments to main, but
I'm pretty sure it's one of the "cd REPO; git log..." commands.  So...

Basically, I can't see how we can get here.

Currently leaning towards a theory that the issue may be that we only
set PSEUDO_PREFIX when we think we want pseudo, and it looks like in
the PSEUDO_DISABLED=1 case, it may be that we can end up with a task
being run in an environment where LD_PRELOAD had been set, but we've
cleaned up our environment, and the disabled path is skipping part of
the environment setup.

Still really weird to me that I can't reproduce this outside of hob.
I am pretty sure there exists a series of forks and execs and
environment changes such that this will end up happening.

-s
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.


  reply	other threads:[~2012-03-23  7:16 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-17 17:35 pseudo interaction issue Paul Eggleton
2012-02-17 18:50 ` Mark Hatle
2012-03-14  9:02   ` Xu, Dongxiao
2012-03-22  1:49     ` Xu, Dongxiao
2012-03-22 16:18       ` Peter Seebach
2012-03-23  1:01         ` Xu, Dongxiao
2012-03-23  2:29           ` Peter Seebach
2012-03-23  3:21             ` Xu, Dongxiao
2012-03-23  7:16               ` Peter Seebach [this message]
2012-03-23 12:20                 ` Paul Eggleton
2012-03-23 20:06                   ` Peter Seebach
2012-03-23 22:45                   ` Peter Seebach
2012-03-24 17:15                     ` Richard Purdie
2012-03-24 17:41                       ` Richard Purdie
2012-03-26 16:44                         ` Peter Seebach
2012-03-26 16:47                           ` Richard Purdie
2012-03-26 17:18                             ` Peter Seebach
2012-03-26 21:45                               ` Richard Purdie
2012-03-27  3:47                                 ` Peter Seebach
2012-03-27 14:26                                 ` Peter Seebach
2012-03-26  7:43                       ` Peter Seebach
2012-03-26  9:23                         ` Richard Purdie
2012-03-26 20:36                       ` Peter Seebach
2012-03-26 20:41                       ` Peter Seebach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120323021635.5b4fc048@wrlaptop \
    --to=peter.seebach@windriver.com \
    --cc=dongxiao.xu@intel.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.