Pseudo Abort: Difference between revisions
(Created page with "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...") |
No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
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. | 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. | As such, the project has decided to throw abort() calls when this is seen. | ||
A key note - the abort calls will trigger if the pseudo update is added and it is not a clean TMPDIR, since paths which should have been ignored will already have made it into the database. Please use a clean TMPDIR when switching to these pseudo patches. We will enforce a TMPDIR version change in configuration to avoid people being bitten by this. | |||
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. | 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. | 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. | ||
If extra debug is needed for a recipe, you can do this by adding export PSEUDO_DEBUG = "nfoPcvdDyerpswikVx" to the recipe. The task log will contain a lot of data. We may also need the log from "strace -f bitbake -c <task> 2> logfilename.txt" in order to understand cases where libc calls are potentially being missed. | |||
Sometimes the abort may be seen as a message from a task like "ERROR: Task [XXX] failed with exit code '134'" which is SIGABRT. In this case the message is happening very early in task startup so logging doesn't work like it normally does. Often this might be the first task to execute under fakeroot which is linux-libc-headers:do_install. The log should still be available as WORKDIR/pseudo/pseudo.log to give information about what failed. | |||
Latest revision as of 12:48, 19 February 2021
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.
A key note - the abort calls will trigger if the pseudo update is added and it is not a clean TMPDIR, since paths which should have been ignored will already have made it into the database. Please use a clean TMPDIR when switching to these pseudo patches. We will enforce a TMPDIR version change in configuration to avoid people being bitten by this.
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.
If extra debug is needed for a recipe, you can do this by adding export PSEUDO_DEBUG = "nfoPcvdDyerpswikVx" to the recipe. The task log will contain a lot of data. We may also need the log from "strace -f bitbake -c <task> 2> logfilename.txt" in order to understand cases where libc calls are potentially being missed.
Sometimes the abort may be seen as a message from a task like "ERROR: Task [XXX] failed with exit code '134'" which is SIGABRT. In this case the message is happening very early in task startup so logging doesn't work like it normally does. Often this might be the first task to execute under fakeroot which is linux-libc-headers:do_install. The log should still be available as WORKDIR/pseudo/pseudo.log to give information about what failed.
