Segfault in remote mode when LOADing HTTPS/ICY stream on ARM (Raspberry Pi)
Brought to you by:
sobukus
Menu
▾
▴
#385 Segfault in remote mode when LOADing HTTPS/ICY stream on ARM (Raspberry Pi)
Description:
mpg123 crashes with a segfault when using LOAD with an HTTPS webradio URL in remote mode (-R) on ARM (Raspberry Pi). The crash occurs in generic_sendstr() when attempting to print the ICY-NAME metadata. The issue reproduces on both 1.32.10 and 1.33.4.
Environment:
Platform: Raspberry Pi (armhf, arm-linux-gnueabihf)
OS: Raspbian Buster (Debian 10)
mpg123 versions tested: 1.32.10 and 1.33.4 (compiled from source)
GDB: Raspbian 8.2.1-2
Configure flags: ./configure --with-audio=alsa --enable-static --disable-shared
Binary is fully statically linked against libmpg123 (confirmed via ldd)
Steps to reproduce:
# Terminal 1
mpg123 -R --fifo /tmp/mpg123-fifo.cmd
# Terminal 2
echo "LOAD https://jazzradio.ice.infomaniak.ch/jazzradio-high" > /tmp/mpg123-fifo.cmd
Observed behavior:
mpg123 outputs @I jazzradio-high then immediately segfaults.
Backtrace (1.33.4):
gdb --args /usr/local/bin/mpg123 -R --fifo /tmp/mpg123-fifo.cmd
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
@R MPG123 (ThOr) v11
[Detaching after fork from child process 23855]
[Detaching after fork from child process 23856]
@I jazzradio-high
Program received signal SIGSEGV, Segmentation fault.
0x76fbc24c in strlen () from /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so
(gdb) bt full
#0 0x76fbc24c in strlen () from /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so
No symbol table info available.
#1 0x000200a0 in utf8outstr (dest_=dest_@entry=0x7efff13c, source=0xb <error: Cannot access memory at address 0xb>, source@entry=0xbec68 "", to_terminal=to_terminal@entry=1)
at src/local.c:290
dest = 0x0
width = 0
source_fill = <optimized out>
#2 0x00020db4 in outstr (dest=0x7efff13c, dest@entry=0x7efff124, str=str@entry=0xbec68 "", is_utf8=is_utf8@entry=1, is_term=1) at src/local.c:449
ret = 0
usrc = <optimized out>
#3 0x00017fec in generic_sendstr (is_utf8=is_utf8@entry=1, fmt=fmt@entry=0x8d688 "I ICY-NAME: %s", str=0xb <error: Cannot access memory at address 0xb>) at src/control_generic.c:81
ap = {__ap = 0x7efff14c}
outbuf = 0x0
#4 0x00018638 in generic_load (state=1, arg=<optimized out>, fr=<optimized out>) at src/control_generic.c:333
No locals.
#5 generic_load (fr=<optimized out>, arg=<optimized out>, state=1) at src/control_generic.c:311
No locals.
#6 0x00019ca8 in control_generic (fr=0x1) at src/control_generic.c:929
toksave = 0x7efff293 ""
len = 0
comstr = <optimized out>
cmd = 0x7efff258 "LOAD"
arg = 0x7efff25d "https://jazzradio.ice.infomaniak.ch/jazzradio-high"
counter = <optimized out>
next_comstr = 0x7efff294 ""
tv = {tv_sec = 0, tv_usec = 0}
fds = {__fds_bits = {8, 0 <repeats 31 times>}}
n = <optimized out>
alive = <optimized out>
silent = <optimized out>
__func__ = "control_generic"
buf = "LOAD\000https://jazzradio.ice.infomaniak.ch/jazzradio-high\000mp3", '\000' <repeats 149 times>...
last_len = 0
#7 0x000139c4 in main (sys_argc=<optimized out>, sys_argv=<optimized out>) at src/mpg123.c:1309
ret = <optimized out>
result = 0
end_of_files = 0 '\000'
parr = 8421440
fname = <optimized out>
libpar = 10
mp = <optimized out>
pl_utf8 = 0
start_time = {tv_sec = 1000, tv_usec = 1996476672}
__func__ = "main"
stderr_width = 2130705400
stdin_width = <optimized out>
term_ctrl_default = 1
(gdb)
Analysis:
The crash happens at src/control_generic.c:333:
if(filept->htd.icy_name.fill) generic_sendstr(1, "I ICY-NAME: %s", filept->htd.icy_name.p);
The guard icy_name.fill passes (non-zero), but icy_name.p is 0xb — a corrupted pointer, not NULL and not a valid address. This suggests the mpg_string struct is getting corrupted upstream, likely during the HTTPS network helper fork/handoff (two "Detaching after fork from child process" messages are visible before the crash).
The issue may be ARM-specific. I have not yet tested whether HTTP (non-TLS) streams also crash.
I cannot reproduce on AMD64. Is this specific to remote control mode or does plain
also crash? It also prints the ICY info for me … though it is not very informative:
Next step would be to check if a stream capture (
--streamdump file) that is then opened with correct--icy-intervalfrom disk also crashes. This isolates things from the actual HTTP process. Of course, the history of the corrupted string struct would be goodEnvironment
- Platform: armv7l (Raspberry Pi, Raspbian Buster/Debian 10)
1. The problem only occurs in remote mode; plain mode works fine
Plain mode plays the stream without issue:
Remote mode crashes:
Output before crash:
2. Stream capture replayed with correct
--icy-intervalfrom disk does NOT crashCaptured the raw stream using curl (since mpg123 crashes in remote mode before completing a dump):
Confirmed the ICY metadata interval:
Result:
icy-metaint: 16000Replayed in remote mode:
This played back successfully with no crash.
3. History of the corrupted string struct
Set a watchpoint on
filept->htd.icy_name.pand a breakpoint ongeneric_load:Sent the LOAD command from another terminal. On first breakpoint hit (entry to
generic_load),fileptis still NULL as expected. Continued, and after the two fork detaches the watchpoint triggered:Hello again !
new update, just tested mpg123 1.31.2, and it is working better, i tryed to use different versions after i have experienced more problems in remote mode (@JUMP -1, not being able to see the frames @F)
i had problems on v1.33.4 and v1.32.10. but using 1.31.2 solves most of them
Last edit: abdelaziz sbaai 2026-04-13
I somehow missed your first response with the streamdump playback check and the gdb logs. I'll have to look at the more closely.
Can you check if a non-https stream using the old internal http code in mpg123 crashes?
./configure --with-network=internalYou got the hunch already, that something in the https helper handling is causing memory corruption.
But that does not make sense: You are using the same helper code with 1.31.x (btw.: 1.31.3 is also fine? Are you able to bisect things? So if it is the change from 1.31.x to 1.32.0, we got broadly revisions 5191 to 5333 to check in trunk. Would be helpful to narrow it down to one of those commits. If you are missing tooling for svn (I'd just do a simple shell script, but some folks are very used to git tools), you could use the github mirror https://github.com/madebr/mpg123 or just the plain git-svn conversion at https://mpg123.org/trunk/.git The relevant commits then are
and
The whole data structure is fishy …
OK, I'm not sure about the getline buffer state right now. Maybe that is even ok, as the lines have been gotten. But it is clear that the
icy_nameandicy_urlstructs are off. Also, both about a MiB in size, with a fill of a few dozen bytes. That is not right. That far you figured out already … I have trouble envisioning how forking off should cause this corruption, especially since mpg123 1.31.x does the same forking.So, some bisecting to the actual revision change that triggers this would be cool.
Hello again !
yes i have tried
./configure --with-network=internalas well as the other options for--with-network(curl, wget), none of them solved the problemi have tryed to bisect to find where the problme occurs exactly, here are the results of the different versions i have tried
So as you guessed, the problem comes from the change from 1.31.x to 1.32.0,
I have noticed another non related problem, the frames don't work in remote mode in the impacted versions
I hope this helps, tell me if you have any questions
Last edit: abdelaziz sbaai 2026-04-20
I don't think that failure to get position information is unrelated. The network backend does not matter, apparently. So it is something in the main process, triggered by that stream … but only if it is really live, not read from a dump. Some memory corruption. Also only in remote control mode …
Since you have the infra set up for testing differing versions. Can you check the commits/revisions between in a bisecting fashion (always taking the middle revision between the currently known-good and currently known-bad one)? If we got a change to pin down, a hunch about the actual mechanism of corruption here could emerge.
Wait, what? The failure to get position information is while playing a local file? That should be super-easy to debug! (Sorry, I'm not fully able to pay attention here.)
Does building with
-fsanitize=addressgive anything? Or ubsan?This can be nicely scripted for bisecting the error. Also … valgrind and/or gdb should be able to pin down something.
Hello again,
i tryed to git bisect, but i ended up skipping many commits because of compilation errors i couldn't fix, so this is the "narrowed down" list of commits where the problem could've happened
is it normal to have compilation errors in some of these commits ?
errors raged from simpler errors like this one
to complicated errors like
There is something else going on. At least on x86-64, I can build all of those 19 commits just fine.
What jumps out is this one:
You do not use buffering, do you? But still, this did touch remote control mode.
The other candidate for bigger changes is
But this is neither specific to ARM, nor does it really touch the remote control interface.
If you could try again to build rev 5291 (commit 3172d2ef48ec160a1101582ffbb1b47a84c54343) and the one before that from a clean checkout … that might be the one. What I did:
This resulted in 19 working builds for me. I normally try to keep trunk commits building.
new update ! i have succeded to compile and run all the previous commits, and problematic versions usings when i tryed this configure option to avoid compilation problems on some commits:
--disable-largefilethe hint was this
makeerrorbut i only had it while compiling some commits when i was bisecting
So you built all those commits and they ran fine without crashing?
Is the current mpg123 also fine with
--disable-largefile?yes, i tested mpg123 1.33.4, and it works just fine
isn't this what this doc file describes ?
https://github.com/madebr/mpg123/blob/master/doc/LARGEFILE
Damn. So you see a corruption issue based on the largefile stuff, which YET AGAIN needs fixing. Hm. Did I break something with the 64 bit API in control_generic.c for 32 bit platforms? Maybe I can reproduce this after all, here.
Can you attach the full configure output / config.log from a normal run of current mpg123 without the --disable-largefile?
yes, here it is
I see the issue with broken position reporting on i686 with largefile:
No crash, but at least an effect. Damn. I again broke something while touching the offset bit mess. This is a really horrible lesson to learn over two decades: If you touch largefile support stuff with 32 or 64 bit offsets, you will get hurt!
PS: Asan doesn't have an issue, though. But there is an issue.
PPS: sf.net: cut that crap about considering me a spambot!
great that you now have a better understading of the bug.
Would you advise i use v1.31.x or v1.33.4 with --disable-largefile ? i'll probably not be playing files larger that 500MB in the worst case scenarios, i'm still wondering if that changes anything in how https streams work
let me know if you want me to test any new commits/patches ;)
thank you for being this reactive !
Can you test current trunk? I found inconsistent largefile usage in control_generic.c. It switched on large offsets too late, after including headers that defined the types.
This is serious breakage and I am appalled that no tooling threw a warning about that. This is another stark highlight on why it is really really really really a bad idea to have the size of off_t depend on a preprocessor macro. I'm working on this for … dunno … 15 years at least now? … and and still get things wrong every single time I have to introduce changes into the machinery to handle this mess.
Anyhow, I really hope current trunk works for you and I can release the bugfix, also for the 1.32 series in distros.
Thanks for spotting the mess.