Closed Seneral closed 1 week ago
Do note most tests filed for me, too, so something seems to be off for me:
FAIL: numserv.py
FAIL: numserv_bsymbolic.py
FAIL: parameters.py
FAIL: recursion.py
XFAIL: blocked.py
FAIL: deadlock.py
FAIL: asunsafe_conversion.py
FAIL: redzone.py
FAIL: revert.py
FAIL: pagecross.py
FAIL: terminal.py
FAIL: syscall_restart.py
FAIL: hidden.py
FAIL: memory_protection.py
FAIL: constructor.py
FAIL: cancel.py
XFAIL: contract.py
FAIL: exception_handling.py
FAIL: missing_function.py
FAIL: access.py
FAIL: access2.py
FAIL: tls.py
FAIL: buildid.py
FAIL: libpulp_messages.py
FAIL: relative_path.py
FAIL: revert_all.py
FAIL: revert_all_target1.py
FAIL: revert_all_target2.py
FAIL: revert_and_patch.py
FAIL: process.py
FAIL: process_revert.py
PASS: livepatchable.py
FAIL: revert_with_invalid.py
FAIL: process_access.py
FAIL: endbr64.py
FAIL: prefix.py
FAIL: dlsym_lock.py
FAIL: pcqueue.py
FAIL: comments.py
FAIL: nolibpulp.py
FAIL: set_patchable.py
FAIL: path_disable.py
FAIL: user_disable.py
FAIL: group_disable.py
SKIP: mprotect_patch.py
PASS: patches.py
FAIL: insn_queue.py
SKIP: chroot.py
FAIL: visibility.py
FAIL: manyprocesses.py
FAIL: stress.py
PASS: tempfiles.py
============================================================================
Testsuite summary for libpulp 0.3.4
============================================================================
# TOTAL: 53
# PASS: 3
# SKIP: 3
# XFAIL: 2
# FAIL: 45
# XPASS: 0
# ERROR: 0
============================================================================
See tests/test-suite.log
Please report to noreply@suse.com
============================================================================
I have a patch for the transposed calloc arguments, I will commit it soon.
As for the failing tests, you may have the yama.ptrace-scope enabled. You can disable it by running:
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
Unfortunately that only made nolibpulp.py pass, the rest is as before. And it wouldn't be a long-term solution for me anyway due to security concerns. What I'm trying to achieve is to make iterations on code faster on a desktop machine, not for patching critical patches on a server. On a desktop, I don't think it's that good of an idea to disable yama. I intend to set prctl(PR_SET_DUMPABLE, 1) within my application in debug mode and see if that works, it would be quite acceptable.
I guess I should ask this, but is this tailored specifically for SUSE and known to not run on other distros? Or should other distros reasonably work as well (even though they might not be explicitly supported)? Thanks for your help so far!
Unfortunately that only made nolibpulp.py pass, the rest is as before. And it wouldn't be a long-term solution for me anyway due to security concerns.
I see. We only support openSUSE at the moment. We had it running on Ubuntu before when the CI was running it, but since we migrated it to openSUSE we did not test it anymore.
The reason why it fails on other distros may be because of how the BuildID and .gnu.note section are generated. You may want to take a look at it. If you apply a patch to a process with ulp trigger -v <patch>
, you will have an detailed information about what happened on the ulp
program side. Then you can use ulp messages -p <PID>
to see what happened on libpulp side.
What I'm trying to achieve is to make iterations on code faster on a desktop machine, not for patching critical patches on a server. On a desktop, I don't think it's that good of an idea to disable yama. I intend to set prctl(PR_SET_DUMPABLE, 1) within my application in debug mode and see if that works, it would be quite acceptable.
I see. We have never tested if it would work with prctl
, but if you do not want to disable YAMA you can also run the ulp
tool as root.
sudo ulp trigger -p <PID> patch.so
Although this is less than ideal, it will work as intended.
I guess I should ask this, but is this tailored specifically for SUSE and known to not run on other distros? Or should other distros reasonably work as well (even though they might not be explicitly supported)? Thanks for your help so far!
As I said, this did work on Ubuntu before, but support for it was dropped when we changed the CI to openSUSE. You will have to debug what is happening with ulp trigger -v
and ulp messages -p <pid>
to check what is failing. My hypothesis is the lack of .gnu.note section, or the lack of sysv BuildID in the binary.
The transposed calloc arguments was fixed in 8b3abce30ee830388f25dbe96041de7d6b02d648
I got the following errors when compiling that do indeed seem to be bugs:
Heres a patch that fixes the errors. calloc_transpose_arg.patch.txt
Though it is quite odd I am getting this error on code that hasn't been touched in 9 months. My gcc version 14.1.1 is over a month old, too