SIGPIPE in Live555 uncaught

When running the VLM with two broadcasts with RTSP streams as their sources, failure in these streams will cause VLC to crash with a SIGPIPE (144). In my case one VLM was feeding several other VLMs with media. All of them crashed after killing the feeds. My guess is this is caused by the fact that Live555 isn't thread safe. This doesn't happen when using only a single stream when chaining VLMs.

Here's a backtrace of what happened at the moment of the crash. The socket was already dead when the sendto() was called, throwing the SIGPIPE.

[#0](https://code.videolan.org/videolan/vlc/-/issues/0)  0x0beb3abd in sendto () from /usr/lib/libc.so.48.0
[#1](https://code.videolan.org/videolan/vlc/-/issues/1)  0x0eb36e52 in sendto (fd=10, msg=0x843f1300, len=133, flags=0, to=0x0, 
    to_len=0) at /usr/src/lib/libpthread/uthread/uthread_sendto.c:52
[#2](https://code.videolan.org/videolan/vlc/-/issues/2)  0x0bee8f64 in send (s=10, msg=0x843f1300, len=133, flags=0)
    at /usr/src/lib/libc/net/send.c:39
[#3](https://code.videolan.org/videolan/vlc/-/issues/3)  0x001e4c38 in RTSPClient::sendRequest ()
   from /usr/local/vlc/lib/vlc/demux/liblive555_plugin.dll
[#4](https://code.videolan.org/videolan/vlc/-/issues/4)  0x001e5e47 in RTSPClient::sendOptionsCmd ()
   from /usr/local/vlc/lib/vlc/demux/liblive555_plugin.dll
[#5](https://code.videolan.org/videolan/vlc/-/issues/5)  0x001b3936 in Connect (p_demux=0x843f1940) at live555.cpp:555
[#6](https://code.videolan.org/videolan/vlc/-/issues/6)  0x001b3936 in Connect (p_demux=0x0) at live555.cpp:555
[#7](https://code.videolan.org/videolan/vlc/-/issues/7)  0x001b3936 in Connect (p_demux=0x2be8b860) at live555.cpp:555
[#8](https://code.videolan.org/videolan/vlc/-/issues/8)  0x001b3936 in Connect (p_demux=0x1710b48) at live555.cpp:555
[#9](https://code.videolan.org/videolan/vlc/-/issues/9)  0x001b3936 in Connect (p_demux=0x2678bff6) at live555.cpp:555
[#10](https://code.videolan.org/videolan/vlc/-/issues/10) 0x001b3936 in Connect (p_demux=0x0) at live555.cpp:555
[#11](https://code.videolan.org/videolan/vlc/-/issues/11) 0x001b3936 in Connect (p_demux=0x0) at live555.cpp:555
[#12](https://code.videolan.org/videolan/vlc/-/issues/12) 0x001b3936 in Connect (p_demux=0x0) at live555.cpp:555
[#13](https://code.videolan.org/videolan/vlc/-/issues/13) 0x001b3936 in Connect (p_demux=0x0) at live555.cpp:555

The system I'm using is running OpenBSD 4.4 i386. I've built VLC from git, commit [e4fb8860]. I've used Live555 v2009.04.20. All of the hardware is connected to a clean private LAN.

assigned to @Courmisch

What version is that? we're blocking SIGPIPE in src/misc/threads.c and live555 is executed in the input thread, which cannot be the main thread.

added Component::Core: Input label

VLC media player 1.1.0-git Goldeneye VLC version 1.1.0-git Goldeneye Compiler: gcc version 4.2.0 20070307 (prerelease)

After further verifications, SIGPIPE is effectively blocked both in VLC (main thread) and in LibVLC (all other threads).

There are thread-safety problems with SIGPIPE signal handling in the live555 RTSP server code, but: 1/ VLC does not use that part of live555, 2/ it should not be relevant with the signal blocked, 3/ this is not the bug tracker for live555.

VLC cannot crash on SIGPIPE. If it happens, then it would seem your operating system is buggy.

added Status::invalid label

closed

I disagree. Blocking a signal does not magically cure the problem. Even if OpenBSD ignores the signal block, it's still VLC that's doing something nasty. Besides, Live555 is not thread-safe and it's used in a threaded environment. That in itself is a problem that should be fixed. It's not sufficient to point at Live555 to fix the problem, because they will simply point out that VLC shouldn't use Live555 in a threaded context to begin with.

At this point VLC is practically useless in relatively complex RTSP setups.

If the OpenBSD decide to ignore specifications because they are allegedly insecure, it is the very least to be expected that they deal with the consequences. The VideoLAN team has enough work fixing its own bugs.

As for live555 thread safety, I can only agree that it is a problem. But assuming a pristine live555, the only possible "proper" fix from the VLC perspective would be not to use the library at all. That is certainly not going to make RTSP more usable in VLC. For the record, interlocking inside the VLC plugin wouldn't work because live555 is doing event handling itself (cf #1730 (closed)). On top of that, live555 exhibits certain behaviours which would in principle mandate a pure single thread process, such as calling signal() or setlocale(). That is not possible. Still, it does not work as badly on more conformant operating systems such as Linux as you report it does on OpenBSD.

I agree Live555 should be replaced by a more competent library. I guess that's something for the long term.

I'm glad things work better on Linux, I'll try to reproduce the exact same circumstances on a Linux machine to be sure. If I find another solution, I'll submit a patch.

mentioned in issue #2984 (closed)