If an InjectEvent callback schedules a timer, the loop will restart,
but the "busy" flag is still false. The fix is to move the "again"
check before the "busy" setting.
Use uri_has_scheme to find out if the href in Webdav responses is absolute
to use the matching base path extraction.
Signed-off-by: Vincent Petry <PVince81@yahoo.fr>
There can be more than one propstat block each with their own status
code. We're only interested in the one with the 200 status, the found
properties.
This fixes parsing to make sure we process all propstat blocks instead
of just the last one, which might have a 404 status for not-found
properties.
Signed-off-by: Vincent Petry <PVince81@yahoo.fr>
Remove additional "a:prop" in PROPFIND request to match RFC 4918 section 9.1.3.
Added Content-Type header as the body is not a true multipart POST.
Signed-off-by: Vincent Petry <PVince81@yahoo.fr>
SocketEvent knows the FD is still open and is about to close it, so
it's unnecessary to rely on the kernel (via AbandonFD) to clean up the
epoll_wait list.
### Why this is relevant
- `AbandonFD` assumes that upon closing the socket, the FD will be automatically removed from the epoll list. That fd is associated with a reference to the `SocketEvent`, so this is an important and dangerous assumption to get wrong. In the case that the FD isn't immediately removed from the list by the kernel, the event loop can crash due to the `SocketEvent` being destroyed and it being a use-after-free bug at that point.
- If a socket FD happens to be duplicated, then closing the SocketEvent FD will not automatically remove it from epoll, and will trigger said bug/crash. It is only automatically removed when all FD references to the underlying socket/resource are closed?
- A `fork()` is one example where a socket FD can be duplicated and result in this situation.
- `CLOEXEC` might be considered mitigation for this but also introduces a race condition where the crash can occur between a `fork()` and `exec()` without additional synchronization to freeze the event loop.
One could argue the mpd event loop isn't fork-safe, and thus should be allowed to use `AbandonFD` however it likes. A decision on whether this is intended should probably be declared; but either way this fix seems appropriate in cases where `Abandon` isn't actually necessary. It also might be possible to fix `AbandonFD` to mark the `SocketEvent` as removed without using `EPOLL_CTL_DEL`?
[edit: made this dependent on HAVE_THREADED_EVENT_LOOP which is always
true for MPD, but not for ncmpc, for example - mk]
This reverts commit 7bc1c9925b. It
caused a crash with the ALSA plugin family (through
MultiSocketMonitor::ReplaceSocketList() and
MultiSocketMonitor::AddSocket()). Until we have a proper fix, the
assertion patch is reverted.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/1020
