3.0 regression: OGG muxer NULL deref

# vlc music.ogm --no-sout-video --sout '#std{access=file,mux=ogg,dst=test.ogg}
...
[000061200006bdd0] mux_ogg mux debug: writing streams headers
[000061200006bdd0] mux_ogg mux debug: creating header for vorb
[000061200006bdd0] mux_ogg mux debug: adding non bos, secondary header
[000061200006bdd0] mux_ogg mux debug: adding non bos, secondary header
[000061200006bdd0] mux_ogg mux debug: data starts from 4277
vlc: ../../src/misc/fifo.c :334 : block_FifoShow:  l'assertion « p_fifo->p_first != ((void *)0) » a échoué.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffd9ca4700 (LWP 12082)]
0x00007ffff56c4107 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56      ../nptl/sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce type.
(gdb) bt

Thread 15 (Thread 0x7fffd9ca4700 (LWP 12082)):
[#0](https://code.videolan.org/videolan/vlc/-/issues/0)  0x00007ffff56c4107 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
[#1](https://code.videolan.org/videolan/vlc/-/issues/1)  0x00007ffff56c54e8 in __GI_abort () at abort.c:89
[#2](https://code.videolan.org/videolan/vlc/-/issues/2)  0x00007ffff56bd226 in __assert_fail_base (
    fmt=0x7fffd682803a "%s%s%s :%u : %s%s l'assertion « %s » a échoué.\n%n", 
    assertion=assertion@entry=0x7ffff46e8160 "p_fifo->p_first != ((void *)0)", 
    file=file@entry=0x7ffff46e8040 "../../src/misc/fifo.c", 
    line=line@entry=334, 
    function=function@entry=0x7ffff46e8220 <__PRETTY_FUNCTION__.6898> "block_FifoShow") at assert.c:92
[#3](https://code.videolan.org/videolan/vlc/-/issues/3)  0x00007ffff56bd2d2 in __GI___assert_fail (
    assertion=0x7ffff46e8160 "p_fifo->p_first != ((void *)0)", 
    file=0x7ffff46e8040 "../../src/misc/fifo.c", line=334, 
    function=0x7ffff46e8220 <__PRETTY_FUNCTION__.6898> "block_FifoShow")
    at assert.c:101
[#4](https://code.videolan.org/videolan/vlc/-/issues/4)  0x00007ffff4501294 in block_FifoShow (p_fifo=0x60c00004d740)
    at ../../src/misc/fifo.c:334
[#5](https://code.videolan.org/videolan/vlc/-/issues/5)  0x00007ffff45a997b in sout_MuxGetStream (p_mux=0x61200006bdd0, i_blocks=1, 
    pi_dts=0x0) at ../../src/stream_output/stream_output.c:568
[#6](https://code.videolan.org/videolan/vlc/-/issues/6)  0x00007fffd9524b00 in Mux (p_mux=0x61200006bdd0)
    at ../../modules/mux/ogg.c:1564
[#7](https://code.videolan.org/videolan/vlc/-/issues/7)  0x00007ffff45a9670 in sout_MuxSendBuffer (p_mux=0x61200006bdd0, 
    p_input=0x61400005fc40, p_buffer=0x6110000507c0)
    at ../../src/stream_output/stream_output.c:539
[#8](https://code.videolan.org/videolan/vlc/-/issues/8)  0x00007fffd998507a in Send (p_stream=0x61200006bf50, id=0x61400005fc40, 
    p_buffer=0x6110000507c0) at ../../modules/stream_out/standard.c:144
[#9](https://code.videolan.org/videolan/vlc/-/issues/9)  0x00007ffff45a6314 in sout_InputSendBuffer (p_input=0x603000182da0, 
    p_buffer=0x6110000507c0) at ../../src/stream_output/stream_output.c:228
[#10](https://code.videolan.org/videolan/vlc/-/issues/10) 0x00007ffff43de8e3 in DecoderPlaySout (p_dec=0x619000162710, 
    p_sout_block=0x6110000507c0) at ../../src/input/decoder.c:775
[#11](https://code.videolan.org/videolan/vlc/-/issues/11) 0x00007ffff43def40 in DecoderProcessSout (p_dec=0x619000162710, 
    p_block=0x0) at ../../src/input/decoder.c:829
[#12](https://code.videolan.org/videolan/vlc/-/issues/12) 0x00007ffff43e42c0 in DecoderProcess (p_dec=0x619000162710, 
    p_block=0x6110000507c0) at ../../src/input/decoder.c:1395
[#13](https://code.videolan.org/videolan/vlc/-/issues/13) 0x00007ffff43e4ce0 in DecoderThread (p_data=0x619000162710)
    at ../../src/input/decoder.c:1484
[#14](https://code.videolan.org/videolan/vlc/-/issues/14) 0x00007ffff5a400a4 in start_thread (arg=0x7fffd9ca4700)
    at pthread_create.c:309
[#15](https://code.videolan.org/videolan/vlc/-/issues/15) 0x00007ffff577506d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

There are two possible reverts to fix it:

• fec56da8 introduced the bug. However, if I revert it, I get a deadlock instead of the crash,
• 5b2c4304 "triggers" the case for the NULL dereference. I do not know if it is safe to revert but it works for me.

added Component::Stream output: Muxers Severity::normal Type::bug Version::master git + 1 deleted label

changed milestone to %Bugs paradize

changed milestone to %3.0.0

of course, tries now to dequeue empty fifo when streams can be added

I think that 5b2c most likely should be change with following:

index 539d2aa..3d87b9b 100644
--- a/src/stream_output/stream_output.c
+++ b/src/stream_output/stream_output.c
@@ -557,9 +557,10 @@ int sout_MuxGetStream( sout_mux_t *p_mux, unsigned 
i_blocks, mtime_t *pi_dts )
         sout_input_t *p_input = p_mux->pp_inputs[i];
         block_t *p_data;
 
-        if( (!p_mux->b_add_stream_any_time) && block_FifoCount( p_input->p_
fifo ) < i_blocks )
+        if( block_FifoCount( p_input->p_fifo ) < i_blocks )
         {
-            if( p_input->p_fmt->i_cat != SPU_ES )
+            if( (!p_mux->b_add_stream_any_time) &&
+                (p_input->p_fmt->i_cat != SPU_ES ) )
             {
                 return -1;
             }

So it would check fifocount on all tracks and only return with -1 from there if streams can't be added at any time, otherwise continuing to check for other tracks.

commit 707e35c8 Author: Ilkka Ollakka ileoo@videolan.org Date: Sat Oct 31 23:03:35 2015 +0200

stream_output: don't skip fifocount check on MuxGetStream

Even if we can add stream in any time, we should just continue
to next track if there isn't enough blocks in this track. Otherwise we
could try to query empty fifo.

ref [#15747](https://code.videolan.org/videolan/vlc/-/issues/15747)

Original author: ileoo@videolan.org

ILEoo: ping?

I didn't close this ticket, as I didn't had time to properly reproduce the issue, but if after that commit that references here, issue can't be reproduced I think it's fixed.

added Status::fixed label

closed

Milestone renamed

changed milestone to %3.0 FF

Milestone renamed