Crash when replaying a trace of Mixxx (part 2)

[napaalm]

Crash when replaying a trace of Mixxx (part 2)

[khuey]

Yeah, open (yet) another issue for that.

[GitMensch]

Do all the tests pass using a current git checkout?

[khuey]

The crash just indicates a generic divergence, this won't be as easy to figure out as the last one unfortunately.

Are you running on Intel hardware? If so, you could try this https://github.com/rr-debugger/rr/wiki/Debugging-divergence#intel-pt

[napaalm]

@khuey I'm on AMD, but I might have found something interesting. In the page you linked there's also the following

In a failed replay, try following the emergency debugger instructions to get a stack. Are you somewhere suspicious, e.g. that might be manipulating memory shared outside the trace?

So, I tried and I got

loop_iterate_cancel (object=0x55980e7ed308, timeout=<optimized out>) at ../pipewire/spa/plugins/support/loop.c:438
438			spa_assert(s->loop == &impl->loop);
(gdb) bt
#0  loop_iterate_cancel (object=0x55980e7ed308, timeout=<optimized out>) at ../pipewire/spa/plugins/support/loop.c:438
#1  0x00007fae39761db2 in do_loop (user_data=0x55980e7c0040) at ../pipewire/src/pipewire/data-loop.c:65
#2  0x00007fae468aa9eb in start_thread (arg=<optimized out>) at pthread_create.c:444
#3  0x00007fae4692e654 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100

Does Pipewire use shared memory, like ALSA? (See #2873)

[napaalm]

I confirm that I'm able to get past the point where it used to crash simply by stopping pipewire (systemctl --user stop pipewire.service pipewire.socket) before running rr record.

Unfortunately now I encountered another crash, so should I open another issue for that and leave this open to discuss the pipewire situation?

[napaalm]

I would add that here Mixxx is trying to use JACK, but I installed pipewire-jack. I don't know if other jack implementations also cause divergence, nor if native pipewire does.

[khuey]

We saw issues with pipewire and Firefox a while back.