Hang after playing the second or third song from modland.com

[cranderson]

After selecting the second or third (or more) song from modland.com in the file browser, ocp hangs. This happens no matter which song(s) are selected--even the same song that works fine the first time might hang the second time (after clearing the cached copy so it gets downloaded again)--I compared the two downloaded copies and they are identical. This is on Fedora 41 x86_64.

[cranderson]

Running with this branch: https://github.com/mywave82/opencubicplayer/commits/download_debug/ as follows:

strace -o ocp-strace2.log -ff ocp 2> ocp2.log

produced the attached log files.
ocp2.log
ocp-strace2.log.732067.txt
ocp-strace2.log.732066.txt
ocp-strace2.log.731800.txt
ocp-strace2.log.731799.txt
ocp-strace2.log.731798.txt
ocp-strace2.log.731797.txt
ocp-strace2.log.731796.txt
ocp-strace2.log.731401.txt

[cranderson]

Recompiled with ALSA_DEBUG=1:

strace -o ocp-strace3.log -ff ocp 2> ocp3.log

ocp-strace3.log.1363110.txt
ocp-strace3.log.1363109.txt
ocp-strace3.log.1362756.txt
ocp-strace3.log.1362755.txt
ocp-strace3.log.1362754.txt
ocp-strace3.log.1362753.txt
ocp-strace3.log.1362752.txt
ocp-strace3.log.1362289.txt
ocp3.log
ocp-strace3.log.1363088.txt
ocp-strace3.log.1363087.txt
ocp-strace3.log.1362814.txt
ocp-strace3.log.1362815.txt
ocp-strace3.log.1362748.txt
ocp-strace3.log.1362711.txt
ocp-strace3.log.1362710.txt
ocp-strace3.log.1362709.txt
ocp-strace3.log.1362708.txt
ocp-strace3.log.1362707.txt
ocp-strace3.log.1362749.txt
ocp-strace3.log.1362703.txt
ocp-strace3.log.1362618.txt
ocp-strace3.log.1362617.txt
ocp-strace3.log.1362616.txt
ocp-strace3.log.1362615.txt
ocp-strace3.log.1362614.txt
ocp-strace3.log.1362705.txt
ocp-strace3.log.1362610.txt
ocp-strace3.log.1362465.txt
ocp-strace3.log.1362464.txt
ocp-strace3.log.1362463.txt
ocp-strace3.log.1362462.txt
ocp-strace3.log.1362461.txt
ocp-strace3.log.1362611.txt
ocp-strace3.log.1362455.txt
ocp-strace3.log.1362315.txt
ocp-strace3.log.1362314.txt
ocp-strace3.log.1362313.txt
ocp-strace3.log.1362312.txt
ocp-strace3.log.1362456.txt

[cranderson]

Additionally set PIPEWIRE_DEBUG=T:

env PIPEWIRE_DEBUG=T strace -o ocp-strace4.log -ff ocp 2> ocp4.log

ocp-strace4.log.1364038.txt
ocp-strace4.log.1364037.txt
ocp-strace4.log.1363825.txt
ocp-strace4.log.1363824.txt
ocp-strace4.log.1363823.txt
ocp-strace4.log.1363822.txt
ocp-strace4.log.1363821.txt
ocp-strace4.log.1363734.txt
ocp4.log
ocp-strace4.log.1364017.txt
ocp-strace4.log.1364016.txt
ocp-strace4.log.1363950.txt
ocp-strace4.log.1363951.txt
ocp-strace4.log.1363762.txt
ocp-strace4.log.1363761.txt
ocp-strace4.log.1363760.txt
ocp-strace4.log.1363759.txt

[mywave82]

I did try to debug this during the spring. I do suspect the issue is in the threading code of pipewire, and OCP is just lucky/unlucky to trigger hanging behaviour.

Optimization level of OCP changed the behaviour. In practice this changes how much of the code and data cache is used, and thereby how multithreading behaves. Pipewire uses multiple threads.

If using helgrind (cache debugging tool), it throws multiple issues. Some of them being in my eyes real potential issues, others are result of pipewire implementing direct memory writes. I'm not experienced enough to fully know how good that logic works, and it might imply that only some key-values are "thread-safe" while the data not written this way might actually not be thread-safe.