Pseudo Abort errors

Pseudo Abort errors

[Phil Reid]

G'day,

Not really sure where to look for this. But started to get random build failures
with the pseudo client.

Failures are contained to populate_sdk

Not always the same file reported in the log and removing tmp-glibc before the build solves the problem.

I've also tried a psudeo_git.bbappend with:
SRCREV = "60e25a36558f1f07dcce1a044fe976b475bec42b"

Which looks to be a pending commit on the list.
Unfortunately it didn't help.

Here's what I think are the relevant parts of the log are below.

"rm -rf tmp-glibc" and a rebuild resolves the problem.


Any thoughts?



-------------------------------------------
One failure:

abort()ing pseudo client by server request. See https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.

relevant pseudo.log:
path mismatch [1 link]: ino 2045493 db 
'/home/cb/build/workspace/soc-image-v2020.04/tmp-glibc/work/cyclone5-emit-linux-gnueabi/emit-image-int/1.0-r0/sstate-build-populate_sdk/x86_64-deploy-emit-image-int-populate-sdk' 
req 
'/home/cb/build/workspace/soc-image-v2020.04/tmp-glibc/work/cyclone5-emit-linux-gnueabi/emit-image-int/1.0-r0/sdk/image/usr/local/emit-x86_64/sysroots/cortexa9t2hf-neon-emit-linux-gnueabi/usr/include/php/main/php_output.h'.
path mismatch [1 link]: ino 2045493 db 
'/home/cb/build/workspace/soc-image-v2020.04/tmp-glibc/work/cyclone5-emit-linux-gnueabi/emit-image-int/1.0-r0/sstate-build-populate_sdk/x86_64-deploy-emit-image-int-populate-sdk' 
req 
'/home/cb/build/workspace/soc-image-v2020.04/tmp-glibc/work/cyclone5-emit-linux-gnueabi/emit-image-int/1.0-r0/sdk/image/usr/local/emit-x86_64/sysroots/cortexa9t2hf-neon-emit-linux-gnueabi/usr/include/php/main/php_output.h'.



find tmp-glibc/ -iname php_output.h -exec ls -la {} \;
-rw-r--r--. 4 cb cb 9642 Feb 22 10:55 
tmp-glibc/work/cortexa9t2hf-neon-emit-linux-gnueabi/emit-dsmain-rel/0.0+svnr52354_52332-r0/recipe-sysroot-native/usr/include/php/main/php_output.h
-rw-r--r--. 4 cb cb 9642 Feb 22 10:55 
tmp-glibc/work/cortexa9t2hf-neon-emit-linux-gnueabi/emit-dsmain-int/0.0+svnr52354_52332-r0/recipe-sysroot-native/usr/include/php/main/php_output.h
-rw-r--r--. 4 cb cb 9642 Feb 22 10:55 
tmp-glibc/work/x86_64-linux/php-native/7.4.9-r0/sysroot-destdir/home/cb/build/workspace/soc-image-v2020.04/tmp-glibc/work/x86_64-linux/php-native/7.4.9-r0/recipe-sysroot-native/usr/include/php/main/php_output.h
-rw-r--r--. 1 cb cb 0 Feb 24 02:12 
tmp-glibc/work/cyclone5-emit-linux-gnueabi/emit-image-int/1.0-r0/sdk/image/usr/local/emit-x86_64/sysroots/cortexa9t2hf-neon-emit-linux-gnueabi/usr/include/php/main/php_output.h
-rw-r--r--. 2 cb cb 9642 Feb 22 10:59 tmp-glibc/work/cortexa9hf-neon-emit-linux-gnueabi/php/7.4.9-r0/sysroot-destdir/usr/include/php/main/php_output.h
-rw-r--r--. 4 cb cb 9642 Feb 22 10:55 tmp-glibc/sysroots-components/x86_64/php-native/usr/include/php/main/php_output.h
-rw-r--r--. 2 cb cb 9642 Feb 22 10:59 tmp-glibc/sysroots-components/cortexa9hf-neon/php/usr/include/php/main/php_output.h

-------------------------------------------
And another one:

abort()ing pseudo client by server request. See https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.

relevant pseudo.log:
path mismatch [1 link]: ino 539813155 db 
'/home/cb/build/workspace/soc-image-v2020.04/tmp-glibc/work/cyclone5-emit-linux-gnueabi/emit-image-int/1.0-r0/sstate-build-populate_sdk/x86_64-deploy-emit-image-int-populate-sdk' 
req 
'/home/cb/build/workspace/soc-image-v2020.04/tmp-glibc/work/cyclone5-emit-linux-gnueabi/emit-image-int/1.0-r0/sdk/image/usr/local/emit-x86_64/sysroots/cortexa9t2hf-neon-emit-linux-gnueabi/usr/include/boost/flyweight/detail/recursive_lw_mutex.hpp'.
d


find tmp-glibc/ -iname recursive_lw_mutex.hpp -exec ls -la {} \;
-rw-r--r--. 4 cb cb 2100 Feb 24 09:59 
tmp-glibc/work/cortexa9t2hf-neon-emit-linux-gnueabi/emit-dsmain-rel/0.0+svnr52371_52332-r0/recipe-sysroot/usr/include/boost/flyweight/detail/recursive_lw_mutex.hpp
-rw-r--r--. 4 cb cb 2100 Feb 24 09:59 
tmp-glibc/work/cortexa9t2hf-neon-emit-linux-gnueabi/boost/1.72.0-r0/sysroot-destdir/usr/include/boost/flyweight/detail/recursive_lw_mutex.hpp
-rw-r--r--. 4 cb cb 2100 Feb 24 09:59 
tmp-glibc/work/cortexa9t2hf-neon-emit-linux-gnueabi/emit-dsmain-int/0.0+svnr52371_52332-r0/recipe-sysroot/usr/include/boost/flyweight/detail/recursive_lw_mutex.hpp
-rw-r--r--. 1 cb cb 0 Feb 25 02:13 
tmp-glibc/work/cyclone5-emit-linux-gnueabi/emit-image-int/1.0-r0/sdk/image/usr/local/emit-x86_64/sysroots/cortexa9t2hf-neon-emit-linux-gnueabi/usr/include/boost/flyweight/detail/recursive_lw_mutex.hpp
-rw-r--r--. 4 cb cb 2100 Feb 24 09:59 tmp-glibc/sysroots-components/cortexa9t2hf-neon/boost/usr/include/boost/flyweight/detail/recursive_lw_mutex.hpp









-- 
Regards
Phil Reid

ElectroMagnetic Imaging Technology Pty Ltd
Development of Geophysical Instrumentation & Software
www.electromag.com.au

23 Junction Parade, Midland WA 6056, AUSTRALIA
Ph: +61 8 9250 8100
Fax: +61 8 9250 7100
Email: preid@electromag.com.au

Re: [OE-core] Pseudo Abort errors

[Richard Purdie]

On Thu, 2021-02-25 at 08:28 +0800, Phil Reid wrote:
> G'day,
> 
> Not really sure where to look for this. But started to get random build failures
> with the pseudo client.
> 
> Failures are contained to populate_sdk
> 
> Not always the same file reported in the log and removing tmp-glibc before the build solves the problem.
> 
> I've also tried a psudeo_git.bbappend with:
> SRCREV = "60e25a36558f1f07dcce1a044fe976b475bec42b"
> 
> Which looks to be a pending commit on the list.
> Unfortunately it didn't help.
> 
> Here's what I think are the relevant parts of the log are below.
> 
> "rm -rf tmp-glibc" and a rebuild resolves the problem.
> 
> 
> Any thoughts?

Which branch and which packaging backend are you using?

There is a bitbake.conf patch on the list changing PSEUDO_IGNORE_PATHS
which would probably help but I need to understand that doesn't have 
side effects and I don't have enough data to do that yet.

Cheers,

Richard

Re: [OE-core] Pseudo Abort errors

[Phil Reid]

On 25/02/2021 18:29, Richard Purdie wrote:
> On Thu, 2021-02-25 at 08:28 +0800, Phil Reid wrote:
>> G'day,
>>
>> Not really sure where to look for this. But started to get random build failures
>> with the pseudo client.
>>
>> Failures are contained to populate_sdk
>>
>> Not always the same file reported in the log and removing tmp-glibc before the build solves the problem.
>>
>> I've also tried a psudeo_git.bbappend with:
>> SRCREV = "60e25a36558f1f07dcce1a044fe976b475bec42b"
>>
>> Which looks to be a pending commit on the list.
>> Unfortunately it didn't help.
>>
>> Here's what I think are the relevant parts of the log are below.
>>
>> "rm -rf tmp-glibc" and a rebuild resolves the problem.
>>
>>
>> Any thoughts?
> 
> Which branch and which packaging backend are you using?
> 
> There is a bitbake.conf patch on the list changing PSEUDO_IGNORE_PATHS
> which would probably help but I need to understand that doesn't have
> side effects and I don't have enough data to do that yet.

G'day Richard,

I'm on the dunfell branch, using package_ipk.

I found the patch for bitbake.conf and I'll give that a go here.




-- 
Regards
Phil Reid

ElectroMagnetic Imaging Technology Pty Ltd
Development of Geophysical Instrumentation & Software
www.electromag.com.au

23 Junction Parade, Midland WA 6056, AUSTRALIA
Ph: +61 8 9250 8100
Fax: +61 8 9250 7100
Email: preid@electromag.com.au

Re: [OE-core] Pseudo Abort errors

[Phil Reid]

On 26/02/2021 07:56, Phil Reid wrote:
> On 25/02/2021 18:29, Richard Purdie wrote:
>> On Thu, 2021-02-25 at 08:28 +0800, Phil Reid wrote:
>>> G'day,
>>>
>>> Not really sure where to look for this. But started to get random build failures
>>> with the pseudo client.
>>>
>>> Failures are contained to populate_sdk
>>>
>>> Not always the same file reported in the log and removing tmp-glibc before the build solves the problem.
>>>
>>> I've also tried a psudeo_git.bbappend with:
>>> SRCREV = "60e25a36558f1f07dcce1a044fe976b475bec42b"
>>>
>>> Which looks to be a pending commit on the list.
>>> Unfortunately it didn't help.
>>>
>>> Here's what I think are the relevant parts of the log are below.
>>>
>>> "rm -rf tmp-glibc" and a rebuild resolves the problem.
>>>
>>>
>>> Any thoughts?
>>
>> Which branch and which packaging backend are you using?
>>
>> There is a bitbake.conf patch on the list changing PSEUDO_IGNORE_PATHS
>> which would probably help but I need to understand that doesn't have
>> side effects and I don't have enough data to do that yet.
> 
> G'day Richard,
> 
> I'm on the dunfell branch, using package_ipk.
> 
> I found the patch for bitbake.conf and I'll give that a go here.
> 

With the following applied, so far today there's been no pseudo aborts.

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 6ada0099eb..c996726d7d 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -687,7 +687,8 @@ SRC_URI = ""
  PSEUDO_LOCALSTATEDIR ?= "${WORKDIR}/pseudo/"
  PSEUDO_PASSWD ?= "${STAGING_DIR_TARGET}:${PSEUDO_SYSROOT}"
  PSEUDO_SYSROOT = "${COMPONENTS_DIR}/${BUILD_ARCH}/pseudo-native"
-PSEUDO_IGNORE_PATHS = 
"/usr/,/etc/,/lib,/dev/,/run/,${T},${WORKDIR}/recipe-sysroot,${SSTATE_DIR},${STAMPS_DIR},${WORKDIR}/pkgdata-sysroot,${TMPDIR}/sstate-control,${DEPLOY_DIR},${WORKDIR}/deploy-,${TMPDIR}/buildstats,${WORKDIR}/sstate-build-package_,${WORKDIR}/sstate-install-package_,${WORKDIR}/sstate-build-image_complete,${TMPDIR}/sysroots-components,${BUILDHISTORY_DIR},${TMPDIR}/pkgdata,${TOPDIR}/cache,${COREBASE}/scripts,${CCACHE_DIR}"
+#PSEUDO_IGNORE_PATHS = 
"/usr/,/etc/,/lib,/dev/,/run/,${T},${WORKDIR}/recipe-sysroot,${SSTATE_DIR},${STAMPS_DIR},${WORKDIR}/pkgdata-sysroot,${TMPDIR}/sstate-control,${DEPLOY_DIR},${WORKDIR}/deploy-,${TMPDIR}/buildstats,${WORKDIR}/sstate-build-package_,${WORKDIR}/sstate-install-package_,${WORKDIR}/sstate-build-image_complete,${TMPDIR}/sysroots-components,${BUILDHISTORY_DIR},${TMPDIR}/pkgdata,${TOPDIR}/cache,${COREBASE}/scripts,${CCACHE_DIR}"
+PSEUDO_IGNORE_PATHS = 
"/usr/,/etc/,/lib,/dev/,/run/,${T},${WORKDIR}/recipe-sysroot,${SSTATE_DIR},${STAMPS_DIR},${WORKDIR}/pkgdata-sysroot,${TMPDIR}/sstate-control,${DEPLOY_DIR},${WORKDIR}/deploy-,${TMPDIR}/buildstats,${WORKDIR}/sstate-build-package_,${WORKDIR}/sstate-install-package_,${WORKDIR}/sstate-build-image_complete,${WORKDIR}/sstate-build-populate_sdk,${WORKDIR}/intercept_scripts-,${TMPDIR}/sysroots-components,${BUILDHISTORY_DIR},${TMPDIR}/pkgdata,${TOPDIR}/cache,${COREBASE}/scripts,${CCACHE_DIR}"

  export PSEUDO_DISABLED = "1"
  #export PSEUDO_PREFIX = "${STAGING_DIR_NATIVE}${prefix_native}"





-- 
Regards
Phil Reid

ElectroMagnetic Imaging Technology Pty Ltd
Development of Geophysical Instrumentation & Software
www.electromag.com.au

23 Junction Parade, Midland WA 6056, AUSTRALIA
Ph: +61 8 9250 8100
Fax: +61 8 9250 7100
Email: preid@electromag.com.au

Re: [OE-core] Pseudo Abort errors

[Richard Purdie]

On Fri, 2021-02-26 at 15:01 +0800, Phil Reid wrote:
> On 26/02/2021 07:56, Phil Reid wrote:
> > On 25/02/2021 18:29, Richard Purdie wrote:
> > > On Thu, 2021-02-25 at 08:28 +0800, Phil Reid wrote:
> > > > G'day,
> > > > 
> > > > Not really sure where to look for this. But started to get random build failures
> > > > with the pseudo client.
> > > > 
> > > > Failures are contained to populate_sdk
> > > > 
> > > > Not always the same file reported in the log and removing tmp-glibc before the build solves the problem.
> > > > 
> > > > I've also tried a psudeo_git.bbappend with:
> > > > SRCREV = "60e25a36558f1f07dcce1a044fe976b475bec42b"
> > > > 
> > > > Which looks to be a pending commit on the list.
> > > > Unfortunately it didn't help.
> > > > 
> > > > Here's what I think are the relevant parts of the log are below.
> > > > 
> > > > "rm -rf tmp-glibc" and a rebuild resolves the problem.
> > > > 
> > > > 
> > > > Any thoughts?
> > > 
> > > Which branch and which packaging backend are you using?
> > > 
> > > There is a bitbake.conf patch on the list changing PSEUDO_IGNORE_PATHS
> > > which would probably help but I need to understand that doesn't have
> > > side effects and I don't have enough data to do that yet.
> > 
> > G'day Richard,
> > 
> > I'm on the dunfell branch, using package_ipk.
> > 
> > I found the patch for bitbake.conf and I'll give that a go here.
> > 
> 
> With the following applied, so far today there's been no pseudo aborts.

Thanks for confirming. I've added some changes in master-next which should
have the same effect. Those should make it through the stable queue to dunfell
but we need to get them into master to start with!

Cheers,

Richard