Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

using async 1 can cause unexpected results #1

Closed
vigata opened this issue Dec 21, 2011 · 0 comments
Closed

using async 1 can cause unexpected results #1

vigata opened this issue Dec 21, 2011 · 0 comments
Assignees
@vigata

Comments

@vigata
Copy link
Owner

vigata commented Dec 21, 2011

using async 1 that fills the audio stream with clear samples can cause the allocation of huge buffers that on some platforms will not fail on allocation. See hisantm.rm
@ghost ghost assigned vigata Dec 21, 2011
@dbpete dbpete mentioned this issue Mar 20, 2015
Open
vigata pushed a commit that referenced this issue Mar 28, 2018
@rbultje
avcodec/h264_slice: don't sync default_ref[] between threads.
8c3b329 
default_ref[] is unconditionally initialized in h264_initialise_ref_list()
(called from ff_h264_build_ref_list(), called from h264_slice_init()).

This fixes the following tsan warning when running fate-h264:

WARNING: ThreadSanitizer: data race (pid=31070)
  Write of size 8 at 0x7bbc000082a8 by thread T1 (mutexes: write M1628):
    #0 memcpy /work/release-test/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:655:5
(ffmpeg+0x10de9d)
    #1 h264_initialise_ref_list ffmpeg/libavcodec/h264_refs.c:214:29 (ffmpeg+0x1186b3f)
    #2 ff_h264_build_ref_list ffmpeg/libavcodec/h264_refs.c:306 (ffmpeg+0x1186b3f)
    #3 h264_slice_init ffmpeg/libavcodec/h264_slice.c:1900:11 (ffmpeg+0x1191149)
[..]
  Previous read of size 8 at 0x7bbc000082a8 by main thread (mutexes:
write M1630):
    #0 memcpy /work/release-test/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:655:5
(ffmpeg+0x10de9d)
    #1 ff_h264_update_thread_context ffmpeg/libavcodec/h264_slice.c:411:5 (ffmpeg+0x118b7dc)

Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
vigata pushed a commit that referenced this issue Mar 28, 2018
@tmm1 @T-bagwell
avformat/hlsenc: fix segfault when using -hls_segment_type fmp4 with …
73bf0f4 
…-hls_segment_filename

previously, specifying -hls_segment_filename meant
s->base_output_dirname was never set, causing a segfault:

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
* frame #0: 0x00007fffbf7d82d0 libsystem_platform.dylib`_platform_strcmp + 80
frame #1: 0x00000001005f4dcf libavformat.57.dylib`io_open_default(s=0x000000010481cc00, pb=0x0000000104806020, url=0x0000000000000000, flags=2, options=0x0000000000000000) at options.c:107
frame #2: 0x0000000100528968 libavformat.57.dylib`hls_mux_init(s=0x000000010481cc00) at hlsenc.c:595
frame #3: 0x00000001005273cb libavformat.57.dylib`hls_write_header(s=0x000000010481cc00) at hlsenc.c:1518
frame #4: 0x00000001005c08d0 libavformat.57.dylib`write_header_internal(s=0x000000010481cc00) at mux.c:486
frame #5: 0x00000001005c0774 libavformat.57.dylib`avformat_write_header(s=0x000000010481cc00, options=0x00000001029026e8) at mux.c:539
@vigata vigata closed this as completed Jun 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@vigata vigata

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@vigata