mywave82
Hang after playing the second or third song from modland.com
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.
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
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
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
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.
