matanbs / webm

Automatically exported from code.google.com/p/webm
0 stars 0 forks source link

EXC_ARM_DA_ALIGN at vp8_bilinear_predict4x4_neon when calling vld1_lane_u32 on armv7 (iPhone 4S) architecture #892

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What is the expected behavior? What do you see instead?
No crash. The codec is crashing.

What version are you using? On what operating system?
master f925e5c
on iOS 7.1.1

Can you reproduce using the vpxdec or vpxenc tools? What command line are
you using?
not tested

Please provide any additional information below.
The issue can be reproduced when establishing a connection from one iPhone A to 
another B running an armv7 architecture. On A turn on the network link 
conditioner and set the bandwidth profile to DSL. At first the image will 
"freeze" without a crash - wait up to two minutes for a crash:

(lldb) bt
* thread #33: tid = 0x11ce2f, 0x0060d24a 
myApp`vp8_bilinear_predict4x4_neon(src_ptr=0x0767b8f3, src_pixels_per_line=272, 
xoffset=<unavailable>, yoffset=6, dst_ptr=0x0750957c, dst_pitch=272) + 162 at 
bilinearpredict_neon.c:47, stop reason = EXC_BAD_ACCESS (code=EXC_ARM_DA_ALIGN, 
address=0x767b6d3)
  * frame #0: 0x0060d24a myApp`vp8_bilinear_predict4x4_neon(src_ptr=0x0767b8f3, src_pixels_per_line=272, xoffset=<unavailable>, yoffset=6, dst_ptr=0x0750957c, dst_pitch=272) + 162 at bilinearpredict_neon.c:47
    frame #1: 0x0060c052 myApp`build_inter_predictors_b(d=<unavailable>, dst=0x0750957c, dst_stride=<unavailable>, base_pre=<unavailable>, pre_stride=<unavailable>, sppf=<unavailable>) + 74 at reconinter.c:189
    frame #2: 0x0060bf20 myApp`build_inter4x4_predictors_mb(x=0x161a5220) + 560 at reconinter.c:509
    frame #3: 0x0063189c myApp`decode_macroblock(pbi=<unavailable>, xd=0x161a5220, mb_idx=<unavailable>) + 212 at decodeframe.c:223
    frame #4: 0x0063150e myApp`decode_mb_rows(pbi=0x161a5220) + 798 at decodeframe.c:650
    frame #5: 0x00630d1e myApp`vp8_decode_frame(pbi=0x161a5220) + 2030 at decodeframe.c:1358
    frame #6: 0x00632e88 myApp`vp8dx_receive_compressed_data(pbi=0x161a5220, size=<unavailable>, source=<unavailable>, time_stamp=4294967296) + 192 at onyxd_if.c:337
    frame #7: 0x0062f3b4 myApp`vp8_decode(ctx=0x16184c08, data=0x070d3000, data_sz=8484, user_priv=0x00000000, deadline=<unavailable>) + 892 at vp8_dx_iface.c:503
    frame #8: 0x006086c6 myApp`vpx_codec_decode(ctx=0x1615dc40, data=0x070d3000, data_sz=8484, user_priv=0x00000000, deadline=0) + 82 at vpx_decoder.c:122
    frame #9: 0x007ee362 myApp`tdav_codec_vp8_decode(self=0x1615da00, in_data=0x15955400, in_size=876, out_data=0x1550c354, out_max_size=0x1550c358, proto_hdr=0x1a0b14f0) + 3918 at tdav_codec_vp8.c:468
    frame #10: 0x007e398a myApp`_tdav_session_video_decode(self=0x1550c1d0, packet=0x1a0a0dd0) + 1346 at tdav_session_video.c:816
    frame #11: 0x007e6112 myApp`_tdav_session_video_jb_cb(data=0x16142e5c) + 78 at tdav_session_video.c:683
    frame #12: 0x007ff554 myApp`_tdav_video_jb_decode_thread_func(arg=0x16142c00) + 1384 at tdav_video_jb.c:480
    frame #13: 0x39ae7918 libsystem_pthread.dylib`_pthread_body + 140
    frame #14: 0x39ae788a libsystem_pthread.dylib`_pthread_start + 102

Xcode shows the location of the crash:

void vp8_bilinear_predict4x4_neon(
        unsigned char *src_ptr,
        int src_pixels_per_line,
        int xoffset,
        int yoffset,
        unsigned char *dst_ptr,
        int dst_pitch) {
    uint8x8_t d0u8, d1u8, d2u8, d3u8, d4u8, d5u8, d6u8;
    uint8x8_t d26u8, d27u8, d28u8, d29u8, d30u8;
    uint8x16_t q1u8, q2u8;
    uint16x8_t q1u16, q2u16;
    uint16x8_t q7u16, q8u16, q9u16;
    uint64x2_t q4u64, q5u64;
    uint64x1_t d12u64;
    uint32x2x2_t d0u32x2, d1u32x2, d2u32x2, d3u32x2;

    if (xoffset == 0) {  // skip_1stpass_filter
        uint32x2_t d28u32 = vdup_n_u32(0);
        uint32x2_t d29u32 = vdup_n_u32(0);
        uint32x2_t d30u32 = vdup_n_u32(0);

        d28u32 = vld1_lane_u32((const uint32_t *)src_ptr, d28u32, 0);
        src_ptr += src_pixels_per_line;
        d28u32 = vld1_lane_u32((const uint32_t *)src_ptr, d28u32, 1);    <<<<<<-- this call crashes consistently
        src_ptr += src_pixels_per_line;
        d29u32 = vld1_lane_u32((const uint32_t *)src_ptr, d29u32, 0);
        src_ptr += src_pixels_per_line;
        d29u32 = vld1_lane_u32((const uint32_t *)src_ptr, d29u32, 1);
        src_ptr += src_pixels_per_line;
        d30u32 = vld1_lane_u32((const uint32_t *)src_ptr, d30u32, 0);
        d28u8 = vreinterpret_u8_u32(d28u32);
        d29u8 = vreinterpret_u8_u32(d29u32);
        d30u8 = vreinterpret_u8_u32(d30u32);
    } else {

I've tried in many ways to compile the library without unaligned access by 
using --disable-fast-unaligned  and also -mstrict-align -mno-unaligned-access 
but nothing seems to solve this problem except --disable-optimizations by 
itself or with -O0. If I increase the optimization level I get the crash.

These are the flags that I'm using right now:

export CFLAGS="-mstrict-align -mno-unaligned-access -O1"
export CXXFLAGS="-mstrict-align -mno-unaligned-access -O1"

configure --target=armv7-darwin-gcc --disable-fast-unaligned --disable-shared 
--enable-static  --disable-examples --disable-docs  --enable-vp8 --disable-vp9 
--enable-realtime-only --enable-onthefly-bitpacking --enable-error-concealment 
--enable-coefficient-range-checking --enable-multi-res-encoding --enable-libyuv 
--disable-optimizations

I'm compiling with Xcode 5.1.1:

clang --version
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

I don't have this problem with armv7s devices.

Original issue reported on code.google.com by machados...@gmail.com on 8 Dec 2014 at 9:16

GoogleCodeExporter commented 9 years ago
This is probably another case of clang aggressively adding alignment directives 
to load/stores.

Original comment by johannko...@google.com on 8 Dec 2014 at 10:46