Opened 5 years ago

Closed 5 years ago

#461 closed enhancement (invalid)

few compiler hitns / warning for version 0.7.4

Reported by: toralf Owned by: michael
Priority: normal Component: ffmpeg
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

I got at an almost stable Gentoo with gcc 4.4.5 :

  • QA Notice: The following files contain runtime text relocations
    • Text relocations force the dynamic linker to perform extra
    • work at startup, waste system resources, and may pose a security
    • risk. On some architectures, the code may not even function
    • properly, if at all.
    • For more information, see http://hardened.gentoo.org/pic-fix-guide.xml
    • Please include the following list of files in your report:
    • TEXTREL usr/lib/libavutil.so.50.43.0
    • TEXTREL usr/lib/libpostproc.so.51.2.0
    • TEXTREL usr/lib/libavdevice.so.52.5.0
    • TEXTREL usr/lib/libswscale.so.0.14.1
    • TEXTREL usr/lib/libavformat.so.52.110.0
    • TEXTREL usr/lib/libavfilter.so.1.80.0
    • TEXTREL usr/lib/libavcodec.so.52.122.0
  • QA Notice: Package may compile
  • fine but exhibit random runtime failures.
  • libavcodec/wmaprodec.c:819: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules
  • libavfilter/libmpcodecs/vf_spp.c:301: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules
  • ffmpeg.c:1082: warning: dereferencing pointer ‘picture2’ does break strict-aliasing rules
  • QA Notice: Package may compile
  • fine but exhibit random runtime failures.
  • libavcodec/h264.c:3592: warning: array subscript is below array bounds
  • QA Notice: Package may compile
  • fine but exhibit random runtime failures.
  • libavcodec/dca.c:1151: warning: array subscript is above array bounds
  • libavcodec/dca.c:1151: warning: array subscript is above array bounds
  • libavcodec/dca.c:1151: warning: array subscript is above array bounds
  • QA Notice: Package may compile
  • fine but exhibit random runtime failures.
  • libavcodec/libx264.c:351: warning: the address of ‘val’ will always evaluate as ‘true’
  • Please do not file a Gentoo bug and instead report the above QA
  • issues directly to the upstream developers of this software.
  • Homepage: http://ffmpeg.org/

Change History (9)

comment:1 Changed 5 years ago by toralf

with new version (0.7.5 and new gcc version 4.5.3) these warnigns still remains:

  • QA Notice: Package triggers severe warnings which indicate that it
  • may exhibit random runtime failures.
  • libavcodec/h264.c:3630:31: warning: array subscript is below array bounds
  • QA Notice: Package triggers severe warnings which indicate that it
  • may exhibit random runtime failures.
  • libavcodec/libx264.c:351:22: warning: the address of ‘val’ will always evaluate as ‘true’
  • Please do not file a Gentoo bug and instead report the above QA
  • issues directly to the upstream developers of this software.
  • Homepage: http://ffmpeg.org/

comment:2 follow-up: Changed 5 years ago by cehoyos

Do you believe any of the notices is valid?
(The notice that val being a char[] and not a char* indicates random runtime failures seems wrong to me.)

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

Replying to cehoyos:

Do you believe any of the notices is valid?

What happens if execute_decode_slices() is called with context_count==0 ?

comment:4 follow-up: Changed 5 years ago by cehoyos

That would require avctx->active_thread_type to have FF_THREAD_SLICE set and avctx->thread_count being 0 at the same time. Afaict, frame_thread_init() in pthreads.c makes this impossible.
Is this not true for win32 threads or do I miss something?

comment:5 in reply to: ↑ 4 Changed 5 years ago by toralf

Replying to cehoyos:

That would require avctx->active_thread_type to have FF_THREAD_SLICE set and avctx->thread_count being 0 at the same time. Afaict, frame_thread_init() in pthreads.c makes this impossible.

Well, maybe that the gcc here under Linux gives a false hit in this case (although I'm not too familar with the code to be sure).

comment:6 Changed 5 years ago by toralf

May a extend this report to these warnings for version 0.7.6) gcc 4.5.3 in the mean while ?) :

Text relocations force the dynamic linker to perform extra

work at startup, waste system resources, and may pose a security
risk. On some architectures, the code may not even function
properly, if at all.
For more information, see http://hardened.gentoo.org/pic-fix-guide.xml
Please include the following list of files in your report:

TEXTREL usr/lib/libavutil.so.50.43.0
TEXTREL usr/lib/libpostproc.so.51.2.0
TEXTREL usr/lib/libavdevice.so.52.5.0
TEXTREL usr/lib/libswscale.so.0.14.1
TEXTREL usr/lib/libavformat.so.52.110.0
TEXTREL usr/lib/libavfilter.so.1.80.0
TEXTREL usr/lib/libavcodec.so.52.122.0

comment:7 Changed 5 years ago by reimar

PIC code has a major performance impact on some code on 32 bit x86, so I at least don't really care about those TEXTREL warnings (and object to the overly dramatic gentoo claims) unless they also happen on any system other than 32-bit x86.

comment:8 Changed 5 years ago by reimar

Also when compiling with --enable-pic only libswscale, libpostproc, libavfilter and libavcodec will contain TEXTRELs.
I don't think that using --enable-pic is a good idea, but complaining about TEXTRELs when not using it is not fair (not that on architectures that have useable PIC support like x86-64 PIC is automatically enabled shared libraries, and 64 bit builds do not contain TEXTRELs).

comment:9 Changed 5 years ago by cehoyos

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

I close this ticket.

If I am wrong assuming that it is impossible to call execute_decode_slices() with context_count==0, please send a patch to ffmpeg-devel.

Afaict, the TEXTRELs are wontfix, if you disagree, please move the discussion to ffmpeg-devel.

Concerning automatic, static code checks: They have been proven unreliable in the past, and given that it seems simple to crash FFmpeg / libavcodec with zzuf, they are not worth the effort imo.

Also note that all developers see the gcc warnings, so I am unsure they have to be posted here.

Note: See TracTickets for help on using tickets.