Pseudo Abort

Pseudo can suffer from problems where files are created or modified in pseudo's fakeroot context, then deleted outside of it. In particular, the inode number for that file may be reused. If some later access under pseudo uses that inode number, pseudo can see this and become confused about whether the files are the same file or not. Under older behaviour for pseudo, the modes of the old file may be applied to the new one, causing mode permission corruption.

As such, the project has decided to throw abort() calls when this is seen.

If you see an abort(), it likely means a file was deleted in a non-pseudo context but was left in pseudo's database. You will usually be able to see the two conflicting file names in the WORKDIR/pseudo/pseudo.log file as a "path mismatch". If you run into this problem, either fix the reason the file was deleted outside of pseudo context, or if you don't understand the problem, report the line from the log file onto the openembedded-core or appropriate layer mailing list.

In more detailed terms, pseudo tracks the full path name each open file descriptor maps to as well as any current chroot and the current working directory. Any file accesses to libc file functions should be resolvable given this data, although pseudo does have to jump through a few hoops to ensure this fd data is correctly maintained. File accesses can sometimes be because this mapping is out of sync with what really happened.