Summary: | dev-libs/glib-2.38.2 - Failed to set PT_PAX markings -mr for: .../work/glib-2.38.2-amd64/tests/.libs/assert-msg-test | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jonathan Lovelace <kingjon3377> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | erikdenstore+gbugs, gentoo, hardened, mikey, rene.rheaume, tka |
Priority: | Normal | Keywords: | NeedPatch, TESTFAILURE |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Build log showing failure |
Description
Jonathan Lovelace
2014-03-09 20:34:13 UTC
Created attachment 372232 [details]
Build log showing failure
With glib-2.38.2-r1, I'm getting an assertion failure on ia64. From test-suite.log: ======================================= glib 2.38.2: tests/test-suite.log ======================================= # TOTAL: 28 # PASS: 27 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: run-assert-msg-test.sh ============================ Test failed: __glib_assert_msg does not have assertion message It _is_ 2.38.2-r1, not 2.38.2 as recorded in test-suite.log. Émeric I can confirm the initial report. Not sure if hardened will know about what is wrong with that pax markings (In reply to Pacho Ramos from comment #4) > Not sure if hardened will know about what is wrong with that pax markings Off the top of my head, I would guess this is because of the order in which things are built. So you may need to patch the build system so that the pax markings are done immediately after the file is built. We provide /usr/sbin/paxmark.sh from the sys-apps/elfix package which is just a simple bash script that does the same pax markings the eclass does, but can be invoked in the middle of a build. Uh, paradoxically we try packages to build tests only when needed with make check and, in cases like this, would be better to make them build, later pax-mark and, after that, run the tests :( Patch run-assert-msg-test.sh so it run paxmark.sh with the needed flags before it run the test. *** Bug 567510 has been marked as a duplicate of this bug. *** I get the same failure message in the test-suite.log. However, while I am also on a hardened profile, I have a vanilla kernel. Thus, there should be no interference from PAX on my system, but the test still fails. It looks like there are two issues: one with the pax-markings and another with the test (on hardened systems?) itself. ======================================= glib 2.48.0: tests/test-suite.log ======================================= # TOTAL: 28 # PASS: 27 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: run-assert-msg-test.sh ============================ Test failed: __glib_assert_msg does not have assertion message FAIL run-assert-msg-test.sh (exit status: 1) This failure is still present in glib-2.50.3. I fiddled around a little with tests/run-assert-msg.test.sh and the output of $LIBTOOL --mode=execute gdb --batch -x ${srcdir:-.}/assert-msg-test.gdb ./assert-msg-test (the part of the test which leads to the failure) is ---- warning: Cannot call inferior functions, Linux kernel PaX protection forbids return to non-executable pages! ** GLib:ERROR:/var/tmp/portage/dev-libs/glib-2.50.3/work/glib-2.50.3/tests/assert-msg-test.c:5:main: assertion failed: (42 < 0) Checking if assert message is in __glib_assert_msg [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGABRT, Aborted. 0x000003fff773221b in raise () from /lib64/libc.so.6 $1 = 0xffffffffaacabef0 <error: Cannot access memory at address 0xffffffffaacabef0> A debugging session is active. Inferior 1 [process 5062] will be killed. Quit anyway? (y or n) [answered Y; input not from terminal] ---- The dmesg entry is (as mentioned already somewhere else): ---- grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/dev-libs/glib-2.50.3/work/glib-2.50.3-abi_x86_64.amd64/tests/.libs/assert-msg-test[assert-msg-test:7609] uid/euid:250/250 gid/egid:250/250, parent /var/tmp/portage/dev-libs/glib-2.50.3/work/glib-2.50.3/tests/run-assert-msg-test.sh[run-assert-msg-:7608] uid/euid:250/250 gid/egid:250/250 PAX: execution attempt in: <anonymous mapping>, 39b566fb000-39b568a7000 39b566fb000 PAX: terminating task: /usr/bin/gdb(gdb):7661, uid/euid: 250/250, PC: 0000039b566fb000, SP: 000003a12f0f7de0 PAX: bytes at PC: cc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PAX: bytes at SP-8: 0000039b566fb000 000003a12f0f7e20 48e89f33de75ce00 0000000000000000 000000111aeeffc0 000000111a85d310 0000000000001dea 000000111d9ab4d0 000000111d90c150 000003a12f0f7eb0 000000111a6bb209 grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/gdb[gdb:7661] uid/euid:250/250 gid/egid:250/250, parent /usr/bin/gdb[gdb:7626] uid/euid:250/250 gid/egid:250/250 ---- This is on an amd64 hardened system with PaX enabled in the kernel. Note that for this output I've already modified the PaX markings of tests/.libs/assert-msg-test by hand. The markings are: # paxctl-ng -v /var/tmp/portage/dev-libs/glib-2.50.3/work/glib-2.50.3-abi_x86_64.amd64/tests/.libs/assert-msg-test /var/tmp/portage/dev-libs/glib-2.50.3/work/glib-2.50.3-abi_x86_64.amd64/tests/.libs/assert-msg-test: PT_PAX : -emr- XATTR_PAX : -emr- Looks like bug 676440 was a duplicate of this. I've removed pax marking from 2.60.6. No, I don't know what that will mean for pax systems, but this is not really supported much anymore, plus this is just a test too, anyways. |