Question about psuedo abort errors


Rusty Howell
 

Hello,

My company is using yocto.  When building our own recipes, I get pseudo abort errors rather often.  I've read the wiki page about them, but I'm not sure exactly what we are doing wrong that is making this happen.  We have many recipes for various libraries and applications.  The files listed in the abort error log are usually C++ header files.

A coworker has told me that setting PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src" in the local.conf will allow bitbake to ignore this error. But in the end, I would like to understand what exactly is the root cause, so that I can adjust our recipes to fix this.

Here is the pseudo.log from the most recent failure. I know a lot of proprietary context is missing for anyone in the OSS community to give super confident answers, but I appreciate any suggestions.

Some context here: 
* We have a legacy git repo that contains the source for several different libraries. 
* We use CMake recursively to build all the libs from the top level.
* Some libs depend on other libs in the repo.
* I am trying to build the recipe "libc4statsclient", which is just one of the libs in the repo.
* The header file shown in the error is part of another library and recipe.


ERROR: Task (/home/rhowell/corex-develop/yocto/sources/c4-distro/meta-c4/recipes-c4/libc4statsdclient/libc4statsdclient_git.bb:do_install) failed with exit code '1'
Pseudo log:
Setup complete, sending SIGUSR1 to pid 3063620.
path mismatch [3 links]: ino 3804719 db '/home/rhowell/corex-develop/yocto/build.imx8mq-core/tmp/work/imx8mq_core-control4-linux/libc4statsdclient/local+AUTOINC+e18ad903a2-r3/package/usr/src/debug/libc4statsdclient/local+AUTOINC+e18ad903a2-r3/git/control4/c4shared/logger/logger.hpp' req '/home/rhowell/corex-develop/yocto/build.imx8mq-core/tmp/work/imx8mq_core-control4-linux/libc4statsdclient/local+AUTOINC+e18ad903a2-r3/git/control4/c4shared/logger/logger.hpp'.

Thanks for your time and any suggestions.
Rusty Howell


Richard Purdie
 

On Thu, 2022-06-09 at 10:38 -0600, Rusty Howell wrote:
My company is using yocto.  When building our own recipes, I get
pseudo abort errors rather often.  I've read the wiki page about
them, but I'm not sure exactly what we are doing wrong that is making
this happen.  We have many recipes for various libraries and
applications.  The files listed in the abort error log are usually
C++ header files.

A coworker has told me that setting PACKAGE_DEBUG_SPLIT_STYLE =
"debug-without-src" in the local.conf will allow bitbake to ignore
this error. But in the end, I would like to understand what exactly
is the root cause, so that I can adjust our recipes to fix this.

Here is the pseudo.log from the most recent failure. I know a lot of
proprietary context is missing for anyone in the OSS community to
give super confident answers, but I appreciate any suggestions.

Some context here: 
* We have a legacy git repo that contains the source for several
different libraries. 
* We use CMake recursively to build all the libs from the top level.
* Some libs depend on other libs in the repo.
* I am trying to build the recipe "libc4statsclient", which is just
one of the libs in the repo.
* The header file shown in the error is part of another library and
recipe.


ERROR: Task (/home/rhowell/corex-develop/yocto/sources/c4-distro/meta-c4/recipes-c4/libc4statsdclient/libc4statsdclient_git.bb:do_install) failed with exit code '1'
Pseudo log:
Setup complete, sending SIGUSR1 to pid 3063620.
path mismatch [3 links]: ino 3804719 db '/home/rhowell/corex-develop/yocto/build.imx8mq-core/tmp/work/imx8mq_core-control4-linux/libc4statsdclient/local+AUTOINC+e18ad903a2-r3/package/usr/src/debug/libc4statsdclient/local+AUTOINC+e18ad903a2-r3/git/control4/c4shared/logger/logger.hpp' req '/home/rhowell/corex-develop/yocto/build.imx8mq-core/tmp/work/imx8mq_core-control4-linux/libc4statsdclient/local+AUTOINC+e18ad903a2-r3/git/control4/c4shared/logger/logger.hpp'.

Thanks for your time and any suggestions.
Starting with the error message, it says that a path of:

WORKDIR/git/control4/c4shared/logger/logger.hpp

was accessed and it was found in the pseudo database as:

WORKDIR/package/usr/src/debug/libc4statsdclient/local+AUTOINC+e18ad903a2-r3/git/control4/c4shared/logger/logger.hpp

This doesn't seem so unusual to me since recipe source files would
often be hardlinked into package/usr/src/debug as part of the build,
however the ordering is backwards, the git/ should be created first,
then the WORKDIR/package one.

I was thinking this was really odd, then I realised you say this
aborted in do_install. WORKDIR/package is created by do_package, *not*
do_install which runs before do_package. This probably starts to hint
at what is going on.

Is this a directory where a previous build has run? If so, what changed
between the build runs?

My suspicion is that WORKDIR/package is being deleted outside of pseudo
and that is confusing things. The question is what/where it is being
deleted. Are you using rm_work?

The WORKDIR/temp/log.task_order file can be interesting to see which
tasks reran and in which order.

I appreciate this isn't an answer but it might give you an idea where
to look...

Cheers,

Richard


Rusty Howell
 

Thanks for the response, Richard.   Is the pseudo database located inside TMPDIR?   I have deleted the TMPDIR at times to try to get my build back to a working state. If the pseudo db is outside TMPDIR, then that would be the most likely cause of this error. But I would think that other OSS recipes would generate this same error after I delete TMPDIR, not just my company ones.


Richard Purdie
 

On Fri, 2022-06-10 at 10:05 -0700, Rusty Howell wrote:
Thanks for the response, Richard.   Is the pseudo database located
inside TMPDIR?   I have deleted the TMPDIR at times to try to get my
build back to a working state. If the pseudo db is outside TMPDIR,
then that would be the most likely cause of this error. But I would
think that other OSS recipes would generate this same error after I
delete TMPDIR, not just my company ones.
The pseudo database is per workdir (i.e. per recipe) in WORKDIR/pseudo.

Cheers,

Richard