Selecting a path to step does not work when (both) path's edges and target nodes are the same when trying to do a synchronized step

[karoliineh]

When there is a situation where the synchronized stepping should start (e.g. there are two threads), and this starts from a path-splitting node, where the edges and target nodes are identical for each of the paths (e.g. a path splitting from the pthread_mutex_lock function), the debugger will log an error ERROR - Cannot step over. Path is ambiguous for breakpoint ... and the user is unable to step forward when selecting a path using "Step into target".

For the following program:

#include <stdio.h>
#include <pthread.h>

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

void *t(void *arg) {
    pthread_mutex_lock(&mutex);
}


int main() {
    pthread_t t1, t2;
    pthread_create(&t1, NULL, t, NULL);
    pthread_create(&t2, NULL, t, NULL);
    pthread_join(t1, NULL);
    pthread_join(t2, NULL);
    return 0;
}

This happens when a breakpoint is set on the line pthread_mutex_lock(&mutex);, where there are two call stacks (one for each thread). In this case, when we select which path we want to take in one thread, a query for the edge in the other thread will be done, but this will now return 2 edges.

The ideal solution would be to synchronously step through the corresponding path in the other thread. However, we can't determine the "matching path" just by looking at the edges or nodes; we can only identify it through the states. Since the states may differ in several ways, it becomes really difficult to know which path in the other thread should be stepped through synchronously.

Thus, right now, an "easy fix" would be that if a query for synchronised stepping is done, and there are more than 1 possible edges to step to in the other thread, the other thread's paths become inaccessible. Otherwise, the debugger will just get stuck, which is not nice.