Opened 5 years ago

Closed 5 years ago

#1108 closed defect (wontfix)

Always using "default" memory handling from mem.c against own implementation of memory allocator and deallocator.

Reported by: mato Owned by: michael
Priority: normal Component: avutil
Version: git-master Keywords: memory, AVDictionary, alloc, free
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

In library avutil function av_free is used and other functions from mem.c. If I have my own memory handling functions, in libavutil always default is used instated of mine. I had situation when for allocation my function was used, however for freeing - default av_free was used from file dict.c from libavutil library. It can lead to crashes.

Change History (6)

comment:1 Changed 5 years ago by cehoyos

Is this a regression?
Is this also reproducible with current git head?

Could you add source code that crashes or at least a backtrace of the crash?

comment:2 Changed 5 years ago by michael

  • Priority changed from important to normal
  • Version changed from 0.10 to git-master

Why do you want to use your own memory allocation functions with AVDict ?
Iam asking so we can understand if there is a use case for this or if we just need to document better that this isnt supported

comment:3 follow-up: Changed 5 years ago by mato

Hi,

According to Your questions:

  • Is this a regression? - i think it is not regression, problem exist in ffmpeg 0.6.2 but in other file: avstring.c
  • Is this also reproducible with current git head? - my project use 0.10 ffmpeg version and if i try compile with head not all is compatible
  • Could you add source code that crashes or at least a backtrace of the crash?

Yes, of course:
There is gdb backtrace:
gdb Backtrace:

Program received signal SIGABRT, Aborted.
0xb7fe1424 in kernel_vsyscall ()
(gdb) bt
#0 0xb7fe1424 in
kernel_vsyscall ()
#1 0xb75dce71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb75e034e in abort () at abort.c:92
#3 0xb76147f7 in libc_message (do_abort=2, fmt=0xb76edc0c "* glibc detected * %s: %s: 0x%s *\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#4 0xb761ebe1 in malloc_printerr (action=<value optimized out>, str=<value optimized out>, ptr=0x807d900) at malloc.c:6283
#5 0xb762050b in _int_free (av=<value optimized out>, p=0x807d8f8) at malloc.c:4795
#6 0xb762369d in
libc_free (mem=0x807d900) at malloc.c:3738
#7 0xb7749584 in av_dict_free () from /media/truecrypt1/work/trunk2_3/src/dlna/target/linux/bin/dms_smm/ffmpeg_libs/libavutil.so.51
#8 0x0807d760 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

And I think more intersting valgrind log for version 0.10:

valgrind log:
==18131== Invalid free() / delete / delete[]
==18131== at 0x4025BF0: free (vg_replace_malloc.c:366)
==18131== by 0x48B6583: av_dict_free (in /media/truecrypt1/work/trunk2_3/src/dlna/target/linux/bin/dms_smm/ffmpeg_libs/libavutil.so.51) You can se that free mettod is system one
==18131== Address 0x4ccad00 is 16 bytes inside a block of size 41 alloc'd
==18131== at 0x402517B: memalign (vg_replace_malloc.c:581)
==18131== by 0x8054C00: alloc_ram (av_mem.c:382)
==18131== by 0x805545C: av_malloc (av_mem.c:699)
==18131== by 0x8055554: av_realloc (av_mem.c:740)
==18131== by 0x8054669: av_realloc_f (av_mem.c:186)
==18131== by 0x40AEAFC: dyn_buf_write (in /media/truecrypt1/work/trunk2_3/src/dlna/target/linux/bin/dms_smm/ffmpeg_libs/libavformat.so.53)
but here function from libavformat realloc use memory handling from av_mem.c (own memory implementation)
==18131==
==18131== Invalid free() / delete / delete[]
==18131== at 0x4025BF0: free (vg_replace_malloc.c:366)
==18131== by 0x48B6592: av_dict_free (in /media/truecrypt1/work/trunk2_3/src/dlna/target/linux/bin/dms_smm/ffmpeg_libs/libavutil.so.51)
==18131== Address 0x4ccb3f0 is 16 bytes inside a block of size 48 alloc'd
==18131== at 0x402517B: memalign (vg_replace_malloc.c:581)
==18131== by 0x8054C00: alloc_ram (av_mem.c:382)
==18131== by 0x805545C: av_malloc (av_mem.c:699)
==18131== by 0x8055554: av_realloc (av_mem.c:740)
==18131== by 0x8054669: av_realloc_f (av_mem.c:186)
==18131== by 0x40AEAFC: dyn_buf_write (in /media/truecrypt1/work/trunk2_3/src/dlna/target/linux/bin/dms_smm/ffmpeg_libs/libavformat.so.53)
==18131==

and valgrind log from 0.6.2 version:
==653== Invalid read of size 4
==653== at 0x4027D42: memcpy (mc_replace_strmem.c:635)
==653== by 0x8052CAE: dlna_memcpy (peer_memory.c:54)
==653== by 0x8055585: av_free (av_mem.c:779)
==653== by 0x40B9627: av_metadata_free (metadata.c:103) and here av_metatdata_free use av_mem.c (ovn implementation)
==653== by 0x8050647: SMDM_command_get_metadata (mpe_server.c:562)
==653== by 0x80501E7: SMDM_server_handle_client (mpe_server.c:338)
==653== by 0x804FE3D: main (mpe_server.c:208)
==653== Address 0x4c3facc is 4 bytes before a block of size 16 alloc'd
==653== at 0x402517B: memalign (vg_replace_malloc.c:581)
==653== by 0x40251D8: posix_memalign (vg_replace_malloc.c:709)
==653== by 0x47527DA: av_malloc (mem.c:83)
==653== by 0x4750743: av_d2str (avstring.c:96)
here av_d2str from avstring.c alloc memory from system
==653== by 0x40B1550: ff_id3v1_read (id3v1.c:217)
==653== by 0x40D72DA: adts_aac_read_header (raw.c:707)
==653== by 0x40ED783: av_open_input_stream (utils.c:458)
==653== by 0x40F1ED6: av_open_input_file (utils.c:612)
==653== by 0x804D27F: SMDM_parser_mpe_query (mpe_parse.c:312)
==653== by 0x804CE70: SMDM_parser_get_metadata (mpe_parse.c:169)
==653== by 0x8050647: SMDM_command_get_metadata (mpe_server.c:562)
==653== by 0x80501E7: SMDM_server_handle_client (mpe_server.c:338)
==653==
==653== Invalid free() / delete / delete[]
==653== at 0x4025BF0: free (vg_replace_malloc.c:366)
==653== by 0x8054CF8: free_ram (av_mem.c:477)
==653== by 0x80555B9: av_free (av_mem.c:787)
==653== by 0x40B9627: av_metadata_free (metadata.c:103)
==653== by 0x8050647: SMDM_command_get_metadata (mpe_server.c:562)
==653== by 0x80501E7: SMDM_server_handle_client (mpe_server.c:338)
==653== by 0x804FE3D: main (mpe_server.c:208)
==653== Address 0x4c3fac0 is 16 bytes before a block of size 16 alloc'd
==653== at 0x402517B: memalign (vg_replace_malloc.c:581)
==653== by 0x40251D8: posix_memalign (vg_replace_malloc.c:709)
==653== by 0x47527DA: av_malloc (mem.c:83)
==653== by 0x4750743: av_d2str (avstring.c:96)
==653== by 0x40B1550: ff_id3v1_read (id3v1.c:217)
==653== by 0x40D72DA: adts_aac_read_header (raw.c:707)
==653== by 0x40ED783: av_open_input_stream (utils.c:458)
==653== by 0x40F1ED6: av_open_input_file (utils.c:612)
==653== by 0x804D27F: SMDM_parser_mpe_query (mpe_parse.c:312)
==653== by 0x804CE70: SMDM_parser_get_metadata (mpe_parse.c:169)
==653== by 0x8050647: SMDM_command_get_metadata (mpe_server.c:562)
==653== by 0x80501E7: SMDM_server_handle_client (mpe_server.c:338)

According to description i mem.c file: line 64

/* You can redefine av_malloc and av_free in your project to use your

memory allocator. You do not need to suppress this file because the
linker will do it automatically. */

I redefined memory handling functions. But You can see in logs that sometimes allocation is called from other place than free. Unfortunatly all av_malloc and av_free functions that makes a problem are called from inside ffmpeg.

Best Regards
Marcin Tomczyk

comment:4 Changed 5 years ago by mato

If You analize log below You can see that dyn_buf_write alloc memory in libavformat and
av_dict_free free in libavutil. If I redefine av_malloc and av_free dyn_buf_write use my implementation but dyn_buf_write use default implementation. That is a problem.

==18131== Invalid free() / delete / delete[]
==18131== at 0x4025BF0: free (vg_replace_malloc.c:366)
==18131== by 0x48B6583: av_dict_free (in /media/truecrypt1/work/trunk2_3/src/dlna/target/linux/bin/dms_smm/ffmpeg_libs/libavutil.so.51) You can se that free mettod is system one
==18131== Address 0x4ccad00 is 16 bytes inside a block of size 41 alloc'd
==18131== at 0x402517B: memalign (vg_replace_malloc.c:581)
==18131== by 0x8054C00: alloc_ram (av_mem.c:382)
==18131== by 0x805545C: av_malloc (av_mem.c:699)
==18131== by 0x8055554: av_realloc (av_mem.c:740)
==18131== by 0x8054669: av_realloc_f (av_mem.c:186)
==18131== by 0x40AEAFC: dyn_buf_write (in /media/truecrypt1/work/trunk2_3/src/dlna/target/linux/bin/dms_smm/ffmpeg_libs/libavformat.so.53) but here function from libavformat realloc use memory handling from av_mem.c (own memory implementation)
==18131==
==18131== Invalid free() / delete / delete[]
==18131== at 0x4025BF0: free (vg_replace_malloc.c:366)
==18131== by 0x48B6592: av_dict_free (in /media/truecrypt1/work/trunk2_3/src/dlna/target/linux/bin/dms_smm/ffmpeg_libs/libavutil.so.51)
==18131== Address 0x4ccb3f0 is 16 bytes inside a block of size 48 alloc'd
==18131== at 0x402517B: memalign (vg_replace_malloc.c:581)
==18131== by 0x8054C00: alloc_ram (av_mem.c:382)
==18131== by 0x805545C: av_malloc (av_mem.c:699)
==18131== by 0x8055554: av_realloc (av_mem.c:740)
==18131== by 0x8054669: av_realloc_f (av_mem.c:186)
==18131== by 0x40AEAFC: dyn_buf_write (in /media/truecrypt1/work/trunk2_3/src/dlna/target/linux/bin/dms_smm/ffmpeg_libs/libavformat.so.53)

next log:

comment:5 in reply to: ↑ 3 Changed 5 years ago by cehoyos

Replying to mato:

  • Is this also reproducible with current git head? - my project use 0.10 ffmpeg version and if i try compile with head not all is compatible

Please elaborate, this sounds like a serious regression.

comment:6 Changed 5 years ago by reimar

  • Resolution set to wontfix
  • Status changed from new to closed

This comment is outdated (I sent a patch to update it), you cannot easily overwrite the allocation functions.
You need to at least remove -Wl,-Bsymbolic from the linker flags, but this will have a potentially measurable performance impact.

Note: See TracTickets for help on using tickets.