Thanks for noting that. Of course libout123 should better use strtok_r() instead of the plain strtok(). I added a change towards that (with the more cautionous state pointer intialized to NULL) to the mpg123 upstream repo.
Am Sun, 08 Dec 2024 20:24:01 +0300 schrieb "Yuriy M. Kaminskiy" <yumkam+deb...@gmail.com>: > ==107307== Invalid read of size 1 > ==107307== at 0x4AE712C: strtok_r (strtok_r.c:47) > ==107307== by 0x4933B23: out123_open (libout123.c:462) > ==107307== by 0x127DB7: main (mpg123.c:1280) > ==107307== Address 0x4c0d458 is 104 bytes inside a block of size 105 free'd > ==107307== at 0x4887B40: free (vg_replace_malloc.c:872) > ==107307== by 0x5B96C97: jack_get_tmpdir (in > /usr/lib/aarch64-linux-gnu/libjack.so.0.0.28) > ==107307== by 0x5B985D3: jack_client_open_aux (in > /usr/lib/aarch64-linux-gnu/libjack.so.0.0.28) > ==107307== by 0x5B98AEF: jack_client_open (in > /usr/lib/aarch64-linux-gnu/libjack.so.0.0.28) But also, libjack using plain strtok() should be a bug, too, right? Multithreading enters the picture just because of JACK here. I realize that libmpg123 with the JACK output module also suddenly becomes multithreaded, so the fix is needed on both sides, anyway. Libout123 of coure should be safe also when called from a multithreaded program that fails to use reentrant functions itself. That it shoots itself via libjack is a funny variant of that. Alrighty then, Thomas
