"qmake -install qinstall" reproducer from the bugzilla ticket still reproduces the issues every time even with latest pseudo, but that might be different root cause than glibc-locale issue.
On Wed, Aug 14, 2019 at 6:02 PM Randy MacLeod <randy.macl...@windriver.com> wrote: > On 8/6/19 2:51 AM, Martin Jansa wrote: > > This is the same reproducer I am using in: > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434 > > but with this SRCREV I haven't reproduced it yet in first 500 > > iterations, so it's definitely improving for me (used to reproduce it at > > least once in first 500 iterations) > > > > Now I'm testing the reproducer with "qmake -install qinstall". > > Any update Martin? > > > > Using a variation of Juro's script and adding a little stress-ng load, > it _seems_ that I can make the problem happen more quickly than without > system stress but it's a shared system so _seems_ is underlined. > > Using stress-ng was supposed to be a quick check to see if I could > get the reproducer down to minutes rather than around an hour. > > Results are promising so I'll continue to use this approach as > I add debugging to pseudo and add an inline, immediate check in > the context of: > > > http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/glibc/glibc-locale.inc?h=master#n72 > to see if the UID/GID are equal to my UID/GID. > > Test runs summaries are below. > > ../Randy > > > > cat src/distro/yocto/b/uid-diff/glibc-locale-stress > #!/bin/bash > > fname='glibc-locale_master_august13' > max=100 > for (( i=1; i <= $max; i++ )) > do > echo "$i/$max ${fname}_$i.log" > bitbake glibc-locale -c cleanall 2>&1 > /dev/null > # add some stress > stress-ng -t 1000 --switch 8 --switch-freq 50000 & > bitbake glibc-locale 2>&1 > ${fname}_$i.log > # Destress > killall -9 stress-ng > if grep -q "host-user-contaminated" ${fname}_$i.log; then > echo "error !" > exit 2 > #else > #rm ${fname}_$i.log > fi > done > > > On a (shared) system where lscpu shows 128 cores > and no stress: > > Trial Iteration Error > 1 44 > 2 19 > > > stress-ng -t 1000 --switch 8 --switch-freq 50000 > > 50000 was just the frequency that generated a high enough > but not too high load. On this systems, each process used ~30% of a cpu. > > Trial Iteration Error > 1 3 > 2 18 > > > stress-ng -t 1000 --switch 16 --switch-freq 50000 > > Trial Iteration Error > 1 3 > 2 1 > 3 11 > > stress-ng -t 1000 --switch 32 --switch-freq 50000 > > Trial Iteration Error > 1 2 > 2 9 > 3 8 > > > stress-ng -t 1000 --switch 64 --switch-freq 50000 > > Trial Iteration Error > 1 4 > 2 13 > 3 >6 > > > stress-ng -t 1000 --mq 64 > 128 processes using 98% cpu each > > Trial Iteration Error > 1 14 > 2 NaN > > Trial 2 was precluded by other users of the shared system complaining! > The idea was to cause more rapid context switches. Later, I might try > this again with say 16 workers. If anyone has a better idea, please > reply. > > EOM > > > > > Regards, > > > > On Tue, Aug 6, 2019 at 12:43 AM Bystricky, Juro > > <juro.bystri...@intel.com <mailto:juro.bystri...@intel.com>> wrote: > > > > I can reproduce the problem fairly easily (and, sadly even with the > > latest commits as 060058bb29f70b244e685b3c704eb0641b736f73 ). > > In my case, it seems easy to reproduce if I have 40+ threads running. > > The reproducer script (below) fails typically within the first 10 > > iterations. > > > > > > #!/bin/bash > > > > fname='glibc-locale_master_august8' > > max=1000 > > for (( i=1; i <= $max; i++ )) > > do > > echo "$i/$max ${fname}_$i.log" > > bitbake glibc-locale -c cleanall 2>&1 > /dev/null > > bitbake glibc-locale 2>&1 > ${fname}_$i.log > > if grep -q "host-user-contaminated" ${fname}_$i.log; then > > echo "error !" > > exit 2 > > #else > > #rm ${fname}_$i.log > > fi > > > > done > > > > ________________________________________ > > From: openembedded-core-boun...@lists.openembedded.org > > <mailto:openembedded-core-boun...@lists.openembedded.org> > > [openembedded-core-boun...@lists.openembedded.org > > <mailto:openembedded-core-boun...@lists.openembedded.org>] on behalf > > of Seebs [se...@seebs.net <mailto:se...@seebs.net>] > > Sent: Saturday, August 03, 2019 7:23 AM > > To: Khem Raj > > Cc: openembedded-core@lists.openembedded.org > > <mailto:openembedded-core@lists.openembedded.org> > > Subject: Re: [OE-core] [PATCH v2] pseudo: Upgrade to latest to fix > > openat() with a directory symlink [NAK] > > > > On Sat, 3 Aug 2019 05:33:46 -0700 > > Khem Raj <raj.k...@gmail.com <mailto:raj.k...@gmail.com>> wrote: > > > > > Will this fix the file ownership issue that we see with > Glibc-locale > > > packages from time to time? > > > > I have no idea. Since I haven't got a reliable reproducer for it, I > > can't test it in a sane way. > > > > -s > > -- > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > <mailto:Openembedded-core@lists.openembedded.org> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > -- > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > <mailto:Openembedded-core@lists.openembedded.org> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > > > > -- > # Randy MacLeod > # Wind River Linux >
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
