abhinav92003
commented
6 months ago Oh I think it's the SF:/opt/actions-runner/_work/dynamorio/dynamorio/suite/tests/linux/eintr.c line written by
Closed abhinav92003 closed 6 months ago
abhinav92003
commented
6 months ago Oh I think it's the SF:/opt/actions-runner/_work/dynamorio/dynamorio/suite/tests/linux/eintr.c line written by
jackgallagher-arm
commented
6 months ago The difference is this line: output:
2024-04-04T21:14:23.5132299Z 206: DA:126,0expected:
2024-04-04T21:14:25.4889115Z 206: DA:126,1which corresponds to this code:
124: pthread_mutex_lock(&lock);
125: while (!child_ready)
126: pthread_cond_wait(&condvar, &lock); // <-- Is this line not executed for some reason?
127: child_ready = false;
128: pthread_mutex_unlock(&lock);Is this just a racy test? If the handler() has been called before the main thread gets to the while loop child_ready will already be set to true and the loop body won't be executed.
/*
* test of restarted syscalls
*/
#include "tools.h"
#include <assert.h>
#include <stdio.h>
#include <string.h>
#include <signal.h>
#include <stdlib.h>
#include <pthread.h>
static pthread_cond_t condvar;
static bool child_ready;
static pthread_mutex_t lock;
static void
handler(int sig)
{
print("in handler %d\n", sig);
/* potentially unsafe but we risk it: we should be in our read syscall */
pthread_mutex_lock(&lock);
child_ready = true;
pthread_cond_signal(&condvar);
pthread_mutex_unlock(&lock);
}
/* snip */
int
main(int argc, char **argv)
{
/* snip */
/* test signal w/ handler */
print("sending SIGUSR1\n");
pthread_kill(thread, SIGUSR1);
/* <-- handler() is executed here, setting child_ready = true */
pthread_mutex_lock(&lock);
while (!child_ready) /* child_ready == true so the loop gets skipped */
pthread_cond_wait(&condvar, &lock);
child_ready = false;
pthread_mutex_unlock(&lock);
/* snip */
return 0;
}You're right -- looks like I was chasing a red herring.
I can modify the expected output to expect either a 0 or 1 for that line.
The tool.drcov.eintr test seems to have started failing on ubuntu-20-arm64-sve. This was observed on #6756, #6757, and #6746.
The test logs mention an output mismatch, but I don't see it.