ff_h264_decode_nal crash on iOS 32/64 bit

[glip]

I'm using static linked ffmpeg in my app, while playing H.264 video files it crashes with EXE_BAD_ACCESS. It's hard to reproduce crash it happens randomly - might happen in a few hours, might in a couple minutes. Crash happens in h264.c, line 261 (first if in for)
#if HAVE_FAST_64BIT
for (i = 0; i + 1 < length; i += 9) {
if (!((~AV_RN64A(src + i) & <-- crash
(AV_RN64A(src + i) - 0x0100010001000101ULL)) &
0x8000800080008080ULL))
continue;
FIND_FIRST_ZERO;
STARTCODE_TEST;
i -= 7;
}
#else

ffmpeg version N-79632-g3ce1988 Copyright (c) 2000-2016 the FFmpeg developers
built with Apple LLVM version 7.3.0 (clang-703.0.29)
configuration: --prefix=build/macx64 --enable-gpl
libavutil 55. 22.101 / 55. 22.101
libavcodec 57. 38.100 / 57. 38.100
libavformat 57. 34.103 / 57. 34.103
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 44.100 / 6. 44.100
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 0.101 / 2. 0.101
libpostproc 54. 0.100 / 54. 0.100

[Carl Eugen Hoyos]

Replying to glip:

configuration: --prefix=build/macx64 --enable-gpl

This does not look like an iOS build.

Please either:

• provide the information required for crash reports as explained on https://ffmpeg.org/bugreports.html
• or explain how I can reproduce the issue.

[glip]

Why not? I builded it to folder to use in my app. I do not know who you can reproduce - my app playing 16 files simultaneously (all H.264), eventually it's crashing. When I run app in debugger this is the point where it crashes - h264.c, line 261

[glip]

Parts of Mac crash report

Version: ???
Code Type: X86-64 (Native)
Parent Process: Qt Creator [525]

Date/Time: 2016-05-02 08:56:34.610 -0400
OS Version: Mac OS X 10.11.4 (15E65)
Report Version: 11

Time Awake Since Boot: 4000 seconds

System Integrity Protection: enabled

Crashed Thread: 7 QThread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000012e0c6000
Exception Note: EXC_CORPSE_NOTIFY

VM Regions Near 0x12e0c6000:

MALLOC_LARGE 000000012dfcc000-000000012e0c6000 [ 1000K] rw-/rwx SM=PRV

-->

MALLOC_LARGE 000000012e1c2000-000000012e2b8000 [ 984K] rw-/rwx SM=PRV

Thread 7 Crashed:: QThread
0 com.yourcompany.app 0x000000010f3adf23 ff_h264_decode_nal + 131 (h264.c:261)

Thread 8:: QThread
0 com.yourcompany.app 0x000000010f3ba0ab get_cabac_noinline + 75 (cabac.h:192)

Thread 9:: QThread
0 com.yourcompany.app 0x000000010f3ba2fd fill_decode_caches + 141 (h264_mvpred.h:461)

Thread 10:: QThread
0 com.yourcompany.app 0x000000010f3ba5e5 fill_decode_caches + 885 (h264_mvpred.h:545)

[Carl Eugen Hoyos]

Please read https://ffmpeg.org/bugreports.html (again):
What is needed is the backtrace of the crashing thread, the disassembly of the current function and a register dump.

[glip]

If I use av_log_set_level(AV_LOG_TRACE) -last I see in app console output is:

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8ffa6e7800] stream 1, sample 877, dts 29262567
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8ffa6e7800] stream 0, sample 1419, dts 30272000
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8ffa6e7800] stream 1, sample 877, dts 29262567
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f90091d5400] stream 0, sample 4456, dts 148681867
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8ffa29ca00] stream 0, sample 3076, dts 102635867
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f9003ff6400] stream 0, sample 5309, dts 113258667
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f9003ff6400] stream 1, sample 2807, dts 112280000
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f9003ff6400] stream 0, sample 5310, dts 113280000
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f9003ff6400] stream 1, sample 2807, dts 112280000
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f9003ff6400] stream 0, sample 5311, dts 113301333
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f9003ff6400] stream 1, sample 2807, dts 112280000
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8ffa29ca00] stream 0, sample 3077, dts 102669233
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8ffa004e00] stream 0, sample 3100, dts 103436667
[h264 @ 0x7f8ffa4ca600] user data:"����������������"
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f90037b1a00] stream 0, sample 2554, dts 85218467
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f90091d5400] stream 0, sample 4457, dts 148715233
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f9003cbe600] stream 0, sample 176, dts 7040000
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f9003cbe600] stream 1, sample 295, dts 6849887
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f90038c7400] stream 0, sample 2932, dts 97831067
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8ffa4a6800] stream 0, sample 670, dts 14293333
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8ffa4a6800] stream 1, sample 399, dts 13313300
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8ffa4a6800] stream 0, sample 671, dts 14314667
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8ffa4a6800] stream 1, sample 399, dts 13313300
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f9003d10e00] stream 0, sample 499, dts 19960000
[h264 @ 0x7f8ffd87a400] user data:"����������������"
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f9004c34c00] stream 0, sample 4538, dts 151417933
The program has unexpectedly finished.

[Carl Eugen Hoyos]

Please reopen this ticket if you can provide the missing information.

[glip]

I'm using lldb. This is crash of 32 bit version:

Sorry, reattached in file

[glip]

I'm not sure yet, but I think this crash might be caused by packet.data not containing extra AV_INPUT_BUFFER_PADDING_SIZE bytes.

[Carl Eugen Hoyos]

Yes, this is the usual explanation.