Closed CyberShadow closed 3 years ago
I don't see what could have caused this problem, I need more information.
Add option --stdout
or paste your log file - the interesting portion of your log is missing in this bug report because you pasted only what was printed to stdout/stderr.
In gdb, go to the stack frame of RewindInputStream::Read
(t 5
, f 4
) and print the following data:
p offset
p head
p tail
p *input
Maybe that gives me an idea where the bug is.
Here you are:
(gdb) p offset
$1 = 64000
(gdb) p head
$2 = 0
(gdb) p tail
$3 = 64000
(gdb) p *input
$4 = {_vptr.InputStream = 0x5555558d7df8 <vtable for MaybeBufferedInputStream+16>, uri = "http://127.103.0.93:8131/", mutex = @0x555555952258, handler = 0x7fffc4001210, ready = true, seekable = false, static UNKNOWN_SIZE = 18446744073709551615, size = 18446744073709551615, offset = 64132, mime = "audio/mpeg"}
client: [110] closed
client: [0] process command "idle"
client: [0] command returned 1
client: [80] process command "status"
client: [80] command returned 0
client: [80] process command "plchangesposid "7""
client: [80] command returned 0
client: [80] process command "playlistinfo "0""
client: [80] command returned 0
client: [80] process command "status"
client: [80] command returned 0
client: [80] process command "replay_gain_status"
client: [80] command returned 0
client: [81] process command "idle"
client: [81] command returned 1
client: [112] opened from 127.0.0.1:59260
client: [112] process command list
client: process command "status"
client: command returned 0
client: process command "currentsong"
client: command returned 0
client: [112] process command list returned 0
client: [112] closed
update: added ****_*/**3/***** *******/***** ******* - ******.MP3
update: reading ****_*/**3/***** *******/***** ******* - ***** ** ** *****.MP3
client: [113] opened from 127.0.0.1:59262
client: [113] process command "idle"
client: [113] command returned 1
client: [80] process command "status"
client: [80] command returned 0
client: [114] opened from 127.0.0.1:59264
client: [114] process command list
client: process command "status"
client: command returned 0
client: process command "currentsong"
client: command returned 0
client: [114] process command list returned 0
client: [114] closed
update: added ****_*/**3/***** *******/***** ******* - ***** ** ** *****.MP3
update: reading ****_*/**3/***** *******/***** ******* - .MP3
update: added ****_*/**3/***** *******/***** ******* - .MP3
update: reading ****_*/**3/***** *******/***** ******* - *** ****.MP3
mpd: ../MPD/src/input/RewindInputStream.cxx:110: virtual size_t RewindInputStream::Read(std::unique_lock<std::mutex>&, void*, size_t): Assertion `tail == (size_t)input->GetOffset()' failed.
update: added ****_*/**3/***** *******/***** ******* - *** ****.MP3
update: reading ****_*/**3/***** *******/***** ******* - * ****** ** ***.MP3
Thread 6 "decoder:mad" received signal SIGABRT, Aborted.
(Sanitized file names)
the interesting portion of your log is missing in this bug report because you pasted only what was printed to stdout/stderr
May I suggest:
diff --git a/src/LogInit.cxx b/src/LogInit.cxx
index 98a8810bd..f67121ea7 100644
--- a/src/LogInit.cxx
+++ b/src/LogInit.cxx
@@ -159,6 +159,7 @@ log_init(const ConfigData &config, bool verbose, bool use_stdout)
/* if MPD was started as a systemd
service, default to journal (which
is connected to fd=2) */
+ FmtDebug(log_domain, "switching logging to systemd");
out_fd = STDOUT_FILENO;
return;
}
@@ -168,9 +169,13 @@ log_init(const ConfigData &config, bool verbose, bool use_stdout)
#endif
#ifdef HAVE_SYSLOG
} else if (StringIsEqual(param->value.c_str(), "syslog")) {
+ FmtDebug(log_domain, "switching logging to syslog");
LogInitSysLog();
#endif
} else {
+ FmtDebug(log_domain,
+ "switching logging to file {}",
+ param->GetPath().c_str());
out_path = param->GetPath();
log_init_file(param->line);
}
:)
Your log is still incomplete (and I still can't explain why there is a mismatch between 64000 and 64132). It now shows a few messages right before the crash, but I don't see the start of playback (which probably happened a few seconds earlier, since you're only at offset 64000). I'd like to see the whole terminal output of:
p nbytes
You can omit all those "update" lines instead of obscuring them, these are not relevant.
Is the stream you're proxying with streamripper public? Maybe I can reproduce the problem with that stream.
Your log is still incomplete
Oh, sorry. With the update
and ffmpeg
lines, it was very large, and the beginning scrolled off my terminal backlog.
Here is a fresh set.
If it helps, perhaps the buffer_before_play "0%"
line in the configuration is relevant?
I made the stream temporarily available at http://hidden/. I don't know if the problem can be reproduced when playing over the Internet (as opposed to localhost), though. It is random, and so far took anywhere from seconds to about 5 minutes to reproduce.
I made the stream temporarily available at
Funny, this crashes streamripper ....
Thread 4 "streamripper" received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x7ffff67a5700 (LWP 1933685)]
__libc_send (flags=<optimized out>, len=16001, buf=0x7fffec000b60, fd=8) at ../sysdeps/unix/sysv/linux/send.c:28
28 ../sysdeps/unix/sysv/linux/send.c: No such file or directory.
(gdb) bt
#0 __libc_send (flags=<optimized out>, len=16001, buf=0x7fffec000b60, fd=8) at ../sysdeps/unix/sysv/linux/send.c:28
#1 __libc_send (fd=8, buf=0x7fffec000b60, len=16001, flags=flags@entry=0) at ../sysdeps/unix/sysv/linux/send.c:23
#2 0x00005555554145fc in send_to_relay (ptr=0x7fffe8000b60, rmi=0x555555678280) at relaylib.c:602
#3 thread_send (arg=0x555555678280) at relaylib.c:686
#4 0x00007ffff7f67ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#5 0x00007ffff7be8def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Ah, sorry, I misunderstood you. That is the relay stream produced by StreamRipper.
Here is my StreamRipper command line:
args=(streamripper
"$url"
-d ~/data/music/Streamed
-D "%S/[%D] %A - %T"
# -r 127.103.0.93:8131
-r 0.0.0.0:8131
-R 0 # no connection limit
-z # don't scan for free ports
-t # don't overwrite in incomplete directory
-k 0 # keep partial
-o version
-u "Music Player Daemon 0.20.21"
--stderr
# --debug
--quiet
--xs-none
) ; exec "${args[@]}"
Found it already. This happens when streamripper closes the stream prematurely, or when streamripper crashes - then the offset is miscalculated by MPD, triggering the assertion failure (only relevant when MPD is compiled with debug mode, which most people should not; not a bug in release builds).
Bug report
Describe the bug
Happens here when playing a StreamRipper relay.
StreamRipper's HTTP server seems broken in a lot of ways, but I think that shouldn't cause crashes in players.
Version
Configuration
Log