1

I have a c++ project which I've been using for a while (on a stable build now), recently I had a new debian setup a few days ago and I've set everything up. I set up ffmpeg like I always do and some of my other projects which also depend on ffmpeg seems to be working fine. I've checked ffplay and it works, along with the many different input videos I'm trying with. However, when I try to run the project mentioned, I get various weird behaviours on different videos. For example: some of them say moov atom not found, some of them throw a seg-fault, some of them just crashes the program without any warnings or segfaults or anything.

Like I've said this is a fresh new debian build and the project is working just fine on other computers including this computer before I got a fresh debian (it was debian before aswell).

Here is how I set up ffmpeg:

  1. Pull ffmpeg from it's github page and checkout to latest stable build branch (5.1)
  2. Sudo install dependencies like libx264-dev and nasm and a few more
  3. run ./configure --extra-libs="-lpthread -lm" --ld="g++" --disable-static --enable-shared --enable-gpl --enable-gnutls --enable-libfreetype --enable-nonfree --enable-libx264 --enable-opencl --enable-opengl
  4. run make, then sudo make install and finally sudo ldconfig.

About the errors:

  • If I'm not getting a seg fault but the program just crashes without any errors, when I run valgrind it doesn't say anything (on .mp4 and .avi files mostly). So I ran with the --leak-check=full flag and get the following output (cropped some of it):
...
==220709== 132 bytes in 1 blocks are possibly lost in loss record 323 of 386
==220709==    at 0x483AB65: calloc (vg_replace_malloc.c:760)
==220709==    by 0x8C67DA0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.8)
==220709==    by 0x8BE51E4: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BE8589: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BCB531: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BC49C7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709==    by 0x40100E8: call_init (dl-init.c:30)
==220709==    by 0x40100E8: _dl_init (dl-init.c:119)
==220709==    by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==220709== 
==220709== 148 bytes in 1 blocks are possibly lost in loss record 327 of 386
==220709==    at 0x483AB65: calloc (vg_replace_malloc.c:760)
==220709==    by 0x8C67DA0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.8)
==220709==    by 0x8BE4FEA: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BE8589: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BD4B2B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BC49D1: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709==    by 0x40100E8: call_init (dl-init.c:30)
==220709==    by 0x40100E8: _dl_init (dl-init.c:119)
==220709==    by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==220709== 
==220709== 148 bytes in 1 blocks are possibly lost in loss record 328 of 386
==220709==    at 0x483AB65: calloc (vg_replace_malloc.c:760)
==220709==    by 0x8C67DA0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.8)
==220709==    by 0x8BE4FEA: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BE8589: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BCFBF3: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BC49D6: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709==    by 0x40100E8: call_init (dl-init.c:30)
==220709==    by 0x40100E8: _dl_init (dl-init.c:119)
==220709==    by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==220709== 
==220709== 184 bytes in 1 blocks are possibly lost in loss record 339 of 386
==220709==    at 0x483AD7B: realloc (vg_replace_malloc.c:834)
==220709==    by 0x8C67DE7: g_realloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.8)
==220709==    by 0x8BE3B76: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BE87AC: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BD67DE: g_param_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BD915A: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BC49DB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709==    by 0x40100E8: call_init (dl-init.c:30)
==220709==    by 0x40100E8: _dl_init (dl-init.c:119)
==220709==    by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==220709== 
==220709== 1,502 (352 direct, 1,150 indirect) bytes in 1 blocks are definitely lost in loss record 368 of 386
==220709==    at 0x4838DEF: operator new(unsigned long) (vg_replace_malloc.c:342)
==220709==    by 0x1D19819D: ???
==220709==    by 0x1D177ED3: ???
==220709==    by 0x1D18AAC9: ???
==220709==    by 0x1D1683B0: ???
==220709==    by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709==    by 0x40100E8: call_init (dl-init.c:30)
==220709==    by 0x40100E8: _dl_init (dl-init.c:119)
==220709==    by 0x4F82AEC: _dl_catch_exception (dl-error-skeleton.c:182)
==220709==    by 0x4014057: dl_open_worker (dl-open.c:758)
==220709==    by 0x4F82A8F: _dl_catch_exception (dl-error-skeleton.c:208)
==220709==    by 0x40138F9: _dl_open (dl-open.c:837)
==220709==    by 0x8D9B257: dlopen_doit (dlopen.c:66)
==220709== 
==220709== LEAK SUMMARY:
==220709==    definitely lost: 384 bytes in 3 blocks
==220709==    indirectly lost: 1,230 bytes in 20 blocks
==220709==      possibly lost: 1,352 bytes in 18 blocks
==220709==    still reachable: 189,789 bytes in 1,437 blocks
==220709==                       of which reachable via heuristic:
==220709==                         stdstring          : 1,845 bytes in 46 blocks
==220709==                         newarray           : 1,536 bytes in 16 blocks
==220709==         suppressed: 12 bytes in 1 blocks
==220709== Reachable blocks (those to which a pointer was found) are not shown.
==220709== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==220709== 
==220709== For lists of detected and suppressed errors, rerun with: -s
==220709== ERROR SUMMARY: 21 errors from 21 contexts (suppressed: 0 from 0)
  • As of writing this I've failed to replicate the error I got before about when I get a seg fault. As of now whether or not I get a segfault or not I'm getting the same output as above.

What could be the reason for this? Am I setting ffmpeg wrong?

Turgut
  • 711
  • 3
  • 25
  • I don't think the leakcheck provides any helpful detail. I'd suggest focusing on reproducing a crash and collecting more information about that instead. – teapot418 Feb 06 '23 at 10:34
  • @teapot418 I agree, it's the best I have atm, I'm trying my best to reproduce it. – Turgut Feb 06 '23 at 11:10
  • If you suspect that the library is exiting your program (with `exit`?) prematurely for some reason, you can try registering an atexit hook and make it crash there to get a coredump/stack trace etc. – teapot418 Feb 06 '23 at 11:15
  • @teapot418 I don't think that is the case, one clue I got is I once got an error from valgrind which told me it was in `av_read_frame` but I'm not sure and I haven't been able to reproduce it yet. Looking at it's source code at https://www.ffmpeg.org/doxygen/trunk/demux_8c_source.html there seems to be no exit's. – Turgut Feb 06 '23 at 11:17
  • What is the _first_ error that Valgrind reports? That is where you should start. – Paul Floyd Feb 06 '23 at 14:34

0 Answers0