| Summary: | dev-python/pypy-7.3.4: test_posix.py broken by sys-apps/sandbox? | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
| Component: | Current packages | Assignee: | Sandbox Maintainers <sandbox> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | python, sam, zima |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | /var/log/portage/dev-python:pypy-7.3.4:20210409-092015.log | ||
I recently fixed something similar in https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=b393720bc6e87d16c5013839553c894f2b163961 and I'm not sure when it broke (might be glibc update). If it fixes failure for you I can cut new release. I just hit a similar issue when rebuilding the world, e.g. with app-arch/cpio and some other packages. It fails on testing long pathnames "confdir3/confdir3/...". The last commit in sandbox Git fixes it, I guess you should make a new release. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ae52a3b75f9e89df81735e7c37ca1c61f67170b7 commit ae52a3b75f9e89df81735e7c37ca1c61f67170b7 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2021-04-10 20:15:52 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2021-04-10 20:20:11 +0000 sys-apps/sandbox: bump up to 2.23 One new change: - libsandbox: fix error handling of absolute_path() in check_syscall() Reported-by: Petr Zima Bug: https://bugs.gentoo.org/781824 Package-Manager: Portage-3.0.18, Repoman-3.0.3 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-apps/sandbox/Manifest | 1 + sys-apps/sandbox/sandbox-2.23.ebuild | 54 ++++++++++++++++++++++++++++++++++++ 2 files changed, 55 insertions(+) (In reply to Petr Zima from comment #2) > I just hit a similar issue when rebuilding the world, e.g. with > app-arch/cpio and some other packages. It fails on testing long pathnames > "confdir3/confdir3/...". The last commit in sandbox Git fixes it, I guess > you should make a new release. Thanks for the confirmation! Pushed sandbox-2.23. Do you know after what packages failures started happening? Could it be glibc-2.23? Or maybe kernel? (In reply to Sergei Trofimovich from comment #4) > (In reply to Petr Zima from comment #2) > > I just hit a similar issue when rebuilding the world, e.g. with > > app-arch/cpio and some other packages. It fails on testing long pathnames > > "confdir3/confdir3/...". The last commit in sandbox Git fixes it, I guess > > you should make a new release. > > Thanks for the confirmation! Pushed sandbox-2.23. Do you know after what > packages failures started happening? Could it be glibc-2.23? Or maybe kernel? I’ve noticed this but I hadn’t actually made the connection yet, it’s been on the list to figure out. glibc-2.33 for me, not happened on other machines (In reply to Sergei Trofimovich from comment #4) > Thanks for the confirmation! Pushed sandbox-2.23. Do you know after what > packages failures started happening? Could it be glibc-2.23? Or maybe kernel? Afaik: app-arch/cpio, app-arch/tar, sys-apps/coreutils, sys-apps/findutils, sys-devel/gdb But probably many more that use the same test, most of the rebuild was skipped. Now I see that the packages actually compiled fine, but "rm -fr $BUILDDIR" in the sandbox failed. Glibc was not affected and it was installed ok. And I don't use kernel from portage. Note that I still use patched paludis here (I know it is not supported anymore), maybe it is relevant. (In reply to Petr Zima from comment #6) d> But probably many more that use the same test, most of the rebuild was > skipped. Now I see that the packages actually compiled fine, but "rm -fr > $BUILDDIR" in the sandbox failed. Glibc was not affected and it was > installed ok. And I don't use kernel from portage. > > Note that I still use patched paludis here (I know it is not supported > anymore), maybe it is relevant. To be precise, there was first the ISE during configure: ... checking whether getcwd handles long file names properly... * /tmp/paludis/sys-apps-sandbox-2.22/work/sandbox-2.22/libsandbox/libsandbox.c:check_syscall():983: failure (Bad address): * ISE: rmdir(confdir3) abs_path: (null) res_path: /confdir3 errno=14: Bad address no ... And subsequently, after all compiles, the "rm -fr $BUILDDIR" fails (which can be paludis specific behaviour). Sounds like it's fixed? |
Created attachment 698823 [details] /var/log/portage/dev-python:pypy-7.3.4:20210409-092015.log Tests work fine with sandbox disabled. lib-python/2.7/test/test_posix.py::unmodified * /tmp/portage/sys-apps/sandbox-2.22/work/sandbox-2.22/libsandbox/libsandbox.c:check_syscall():983: failure (Bad address): * ISE: rmdir(getcwd-test-directory-0123456789abcdef-01234567890abcdef) abs_path: (null) res_path: /getcwd-test-directory-0123456789abcdef-01234567890abcdef errno=14: Bad address FAILED [...] test_getcwd_long_pathnames (test.test_posix.PosixTester) ... /usr/lib64/libsandbox.so(+0xc985)[0x7fb1483a6985] /usr/lib64/libsandbox.so(+0xca9e)[0x7fb1483a6a9e] /usr/lib64/libsandbox.so(+0x5ff1)[0x7fb14839fff1] /usr/lib64/libsandbox.so(rmdir+0x29)[0x7fb1483a38d9] /tmp/portage/dev-python/pypy-7.3.4/work/pypy2.7-v7.3.4-src/pypy-c(+0x173ecc4)[0x557476f27cc4] /tmp/portage/dev-python/pypy-7.3.4/work/pypy2.7-v7.3.4-src/pypy-c(+0x2757a88)[0x557477f40a88] /tmp/portage/dev-python/pypy-7.3.4/work/pypy2.7-v7.3.4-src/pypy-c(+0x1f0e124)[0x5574776f7124] /tmp/portage/dev-python/pypy-7.3.4/work/pypy2.7-v7.3.4-src/pypy-c(+0x178332f)[0x557476f6c32f] /tmp/portage/dev-python/pypy-7.3.4/work/pypy2.7-v7.3.4-src/pypy-c(+0x17fee58)[0x557476fe7e58] /tmp/portage/dev-python/pypy-7.3.4/work/pypy2.7-v7.3.4-src/pypy-c(+0x2164894)[0x55747794d894] /proc/4205/cmdline: /tmp/portage/dev-python/pypy-7.3.4/work/pypy2.7-v7.3.4-src/pypy-c /tmp/portage/dev-python/pypy-7.3.4/work/pypy2.7-v7.3.4-src/pypy/tool/pytest/run-script/regrverbose.py test_posix