Bug 509406

For the setcred fail, the full extra error is

==9528== Conditional jump or move depends on uninitialised value(s)
==9528==    at 0x4D2CC8A: setcred (in /lib/libsys.so.7)
==9528==    by 0x201849: main (setcred.cpp:26)
==9528==  Uninitialised value was created by a heap allocation
==9528==    at 0x484E224: malloc (vg_replace_malloc.c:451)
==9528==    by 0x2017D8: main (setcred.cpp:9)

And it looks like the conditional error is when checking the carry flag after the syscall. Strange.

For bug452274 it looks like the interval timer has conked out or just isn't getting scheduled.

I can reproduce a hang if I run the TC outside of Valgrind, something like

 /usr/bin/time sh -c "none/tests/freebsd/bug452274  > /dev/null 2>&1"

Without the redirection (so going to a terminal over ssh) then the TC runs about 5x slower than natively.

I'll wait and see if the problem persists when I upgrade my main macchine to 15.0.

On arm64 I get

./drd/tests/fork-parallel.stderr.diff

Needs a new suppression?

+Thread 3:
+Conflicting store by thread 3 at 0x........ size 1
+   at 0x........: ??? (in /...libc...)
+   by 0x........: ??? (in /...libc...)
+   by 0x........: ??? (in /...libc...)
+   by 0x........: _malloc_postfork (in /...libc...)
+   by 0x........: start_thread
+   by 0x........: start_thread
+   by 0x........: startproc (fork.c:?)
+   by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
+   by 0x........: start_thread
+   by 0x........: pthread_crestart_thread
+Allocation context: unknown.
+


./gdbserver_tests/mcinvokeWS.stdoutB.diff
./gdbserver_tests/mcinvokeWS.stderrB.diff

No output

./gdbserver_tests/nlcontrolc.stderr.diff
./gdbserver_tests/nlcontrolc.stdoutB.diff
./gdbserver_tests/nlsigvgdb.stderrB.diff
./gdbserver_tests/nlvgdbsigqueue.stderr.diff
./gdbserver_tests/nlvgdbsigqueue.stdoutB.diff

+valgrind: m_gdbserver/m_gdbserver.c:881 (void vgPlain_invoke_gdbserver(int)): Assertion 'check == 0x8BADF00D' failed.

./memcheck/tests/freebsd/pdfork_pdkill.stderr.diff

+Conditional jump or move depends on uninitialised value(s)
+   ...
+   by 0x........: main (pdfork_pdkill.c:105)
+

       pdfork(&anotherfd, badflag);

Strange.

./memcheck/tests/freebsd/scalar.stderr.diff

+Syscall param inotify_add_watch_at(mask) contains uninitialised byte(s)
+   ...
+

That's my fault. The syscall has 4 args and I only put 3 in scalar.c. Fixed.

./memcheck/tests/freebsd/timing_safe.stderr.diff

Several changes. Some missing and some changed errors. Not sure what is going on. Maybe on amd64 the compiler is replacing timingsafe_memcmp calls with code.

./none/tests/freebsd/auxv.stderr.diff
./none/tests/freebsd/auxv_script.stderr.diff

#define AT_CHERI_STATS  37      /* Reserved */
#define AT_HWCAP3       38      /* CPU feature flags 3. */
#define AT_HWCAP4       39      /* CPU feature flags 4. *

^^^ look like new entries that need to be handled

Added a suppression for the DRD failure on arm64.
Updated the none auxv tests so that the guest runs first to generate the expexted. That should make it more reliable and only break when new AT_ items are added to auxv.

On amd64 I now get
./gdbserver_tests/nlcontrolc.stderr.diff
^^^ error message from select
./gdbserver_tests/nlvgdbsigqueue.stdoutB.diff
./gdbserver_tests/nlvgdbsigqueue.stderr.diff
^^^ simulate_control_c could not determine the vgdb pid
./memcheck/tests/freebsd/setcred.stderr.diff
^^^ as before, really annoying

On arm64
./gdbserver_tests/mcinvokeWS.stdoutB.diff
./gdbserver_tests/mcinvokeWS.stderrB.diff
./gdbserver_tests/nlcontrolc.stderr.diff
./gdbserver_tests/nlcontrolc.stdoutB.diff
./gdbserver_tests/nlsigvgdb.stderrB.diff
./gdbserver_tests/nlvgdbsigqueue.stderr.diff
./gdbserver_tests/nlvgdbsigqueue.stdoutB.diff
^^^ as before
./memcheck/tests/freebsd/timing_safe.stderr.diff
^^^ another annoying one
./memcheck/tests/thread_alloca.stderr.diff
^^^ has always been a bit flaky, now failing consistently

I just looked at the gdbserver failures. In 2 of the cases (and probably the third, just not in the diffs) there is an assert firing.

How this is supposed to work:

invoker_invoke_gdbserver uses ptrace to modify the running Valgrind tool execution context. For arm64 the relevant bit is

      reg_mod.x[0] = check;
      reg_mod.sp = sp;
      reg_mod.elr = shared64->invoke_gdbserver;
      /* put NULL return address in Link Register */
      reg_mod.lr = bad_return;

So that's setting up the stack pointer, program counter (same as exception link register, dunno why), a phoney return address (s'pose the code wil get back via longjmp hyperspace) and in the x0 register the value of 'check', 0x8BADF00D.

On the other side, void VG_(invoke_gdbserver) ( int check ) contains

   vg_assert (check == 0x8BADF00D);

and that assert is failing. If I just comment out the assert then all the gdbserver tests pass on arm64.

I did a printf of the value of 'check' and it was 4.

There are only two things that I can see as possibilities. 

1.    if (ptrace(PT_SETREGS, pid, (caddr_t)regs, 0) < 0) {
^^^ if this has changed in some way in FreeBSD 15. I need to run the tests with -d to get traces for that.

2. Some compiler oddity at the receiving end. What I might be able to do there is to put a sleep in the code and then attach gdb to try to see what is happening.

The first problem in timing_safe is that timingsafe_memcmp isn't getting redirected. It isn't in the names that generate_and_add_actives processes.

The arm64 issue with timingsafe_memcmp is a FreeBSD bug. They use macros for the begin and end of asm functions. Looks like a copy and paste error, timingsafe_memcmp ends with END(timingsafe_bcmp).

See
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289845

Using clang19 (same as default FreeBSD 15 compiler)  on FreeBSD 14.2 didn't change anything.

I've modified vgdb on arm64 to print out the first 10 32bit words from invoker_invoke_gdbserver using ptrace:

^CDEBUG: invoker_invoke_gdbserver 10 32bit words of instructions
a9be7bfd
f9000bf3
910003fd
529e01a8
72b175a8
6b08001f
54000c61
f0008bf3
b9425a68
350004e8

According to objdump that should be

Disassembly of section .text:

0000000000000e48 <vgPlain_invoke_gdbserver>:

/* Using ptrace calls, vgdb will force an invocation of gdbserver.
   VG_(invoke_gdbserver) is the entry point called through the
   vgdb ptrace technique. */
void VG_(invoke_gdbserver) ( int check )
{
     e48:       a9be7bfd        stp     x29, x30, [sp, #-32]!
     e4c:       f9000bf3        str     x19, [sp, #16]
     e50:       910003fd        mov     x29, sp
     e54:       529e01a8        mov     w8, #0xf00d                     // #61453
     e58:       72b175a8        movk    w8, #0x8bad, lsl #16
      gdbserver. Otherwise, we let the valgrind scheduler invoke
      gdbserver at the next poll.  This poll will be made very soon
      thanks to a call to VG_(force_vgdb_poll). */
   int n_tid, vgdb_interrupted_tid_local = 0;

   vg_assert (check == 0x8BADF00D);
     e5c:       6b08001f        cmp     w0, w8
     e60:       54000c61        b.ne    fec <vgPlain_invoke_gdbserver+0x1a4>  // b.any

   if (busy) {
     e64:       90000013        adrp    x19, 0 <vgPlain_ppPointKind>
     e68:       b9400268        ldr     w8, [x19]
     e6c:       350004e8        cbnz    w8, f08 <vgPlain_invoke_gdbserver+0xc0>

That's not quite the same, the two words after the addert are different.

I should have done an objdump of none-arm64-freebsd
When I do that the words are the same.

Calling getregs before gives me c0000998 in x0.
Putting 0x8BADFOOD also in x[1]  shows up correctly if I add a 2nd argument.

Really scratching my head with this.

Setting

 debug.ptrace_attach_transparent=0

(needs root privs)

works around the arm64 gdbserver failures.

For the arm64 gdbserver issues

sudo sysctl debug.ptrace_attach_transparent=0

is a workaround

See also

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290008

So now on arm64 I have the following issues

memcheck/tests/freebsd/pdfork_pdkill     (stderr)
^^^
One extra Conditional jump or move depends on uninitialised value(s)

memcheck/tests/freebsd/timing_safe       (stderr)
^^^
Should be fixed in FreeBSD soon

memcheck/tests/thread_alloca             (stderr)
^^^
has been slightly flaky for a long time, now consistently flaky

+Syscall param sigprocmask(set) points to uninitialised byte(s)

FreeBSD 15.0-ALPHA5 aarch64 contains a fix for the timingsafe_memcmp

The setcred testcase also fails on FreeBSD 14.3 amd64.

Fixed as much as possible.