Crash on Redmi Note 3 Pro - read memory from 0xef2d7f5c failed

[proxain]

App crashes few seconds after starting attempting to get

char y = Y_row[w_offset + j];

I debugging what happens and I find Y_row give me

read memory from 0xef2d7f5c failed (0 of 1 bytes read)

size of Y_len is 40 944 but in this line trying to get Y_row from Y_data[(h_offset + i) * w] which is equal to Y_data[44880]. Also applying stack trace generated with ndk-stack

********** Crash dump: **********
Build fingerprint: 'Xiaomi/kenzo/kenzo:6.0.1/MMB29M/7.4.13:user/release-keys'
pid: 1263, tid: 1508, name: Camera Backgrou >>> facebook.f8demo <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xf3f01000
Stack frame #00 pc 002c8e24 /data/app/facebook.f8demo-2/lib/arm/libnative-lib.so (Java_facebook_f8demo_ClassifyCamera_classificationFromCaffe2+547): Routine Java_facebook_f8demo_ClassifyCamera_classificationFromCaffe2 at /home/todor/git/gittest/AICamera/app/src/main/cpp/native-lib.cpp:96
Stack frame #1 pc 000ea919 /system/lib/libart.so (art_quick_generic_jni_trampoline+40)
Stack frame #2 pc 000e6221 /system/lib/libart.so (art_quick_invoke_stub_internal+64)
Stack frame #3 pc 003eb5bb /system/lib/libart.so (art_quick_invoke_stub+170)
Stack frame #4 pc 00101f34 [stack:1508]

[DuinoDu]

I meet similar problem:

A/libc: Fatal signal 11 (SIGSEGV), code 2, fault addr 0xe8288000 in tid 22692 (Camera Backgrou)

Do you have any idea about it?

[bwasti]

this is probably an issue with this TODO:
https://github.com/bwasti/AICamera/blob/master/app/src/main/java/facebook/f8demo/ClassifyCamera.java#L220-L222

I will look into it

[lzx1413]

@DuinoDu @proxain I think the reason is that the image size set in java file is 227x227, but the real size of the image captured is smaller that that, so the image size set in jni file may be bigger than the real buffer size, so the program crash.

[ghost]

I was getting a similar (probably the same) error. The problem seems to be that when you iterate through the image rows in Java_facebook_f8demo_ClassifyCamera_classificationFromCaffe2, you divide the memory location for the U and V channels by 2, when you should be dividing by 4 (as both height and width have been halved), i.e. jbyte* U_row = &U_data[(h_offset + i) / 4 * w];

In my case I was still getting junk classification results, which turned out to be due to my image being padded (I think this might be device dependent) so I replaced w in the above line with the row stride (in my case 512).

[bwasti]

@m00nkeh is probably right. Looking at this I think I did the math wrong.

[xshipeng]

I think the transformation from YUV420 to RGB has some problems with @m00nkeh's revision. The structure for YUV420 in Android is not the same as the one in this.There are several formats for YUV420. And when I print the length for Y U V channel, I got 'Y_len:76800 U_len:38399 V_len:38399'. And I think the reason for this result is that the YUV420 format in Android is NV12 rather than YV12. The U and V channels share the same plane, so the memory location for U and V channels should be divided by 2 rather than 4. So I think @bwasti is right.

I have also done some experiments: print the input_data in JNI to a file

if(writingdata){
        alog("Writing input data\n");
        std::ofstream ofs("/sdcard/test.txt",std::ios::out|std::ios::trunc);
        for (int i=0;i<MAX_DATA_SIZE;i++){
            ofs<<input_data[i]<<std::endl;
        }
        ofs.close();
    }

pull the file with ADB and restore the picture with this on PC. If dividing the memory location for U and V by 4, the location of color in restored pictures will shift greatly. However, if the location is divided by 2, the restored picture is correct. I have tested on OnePlus 5 and Pixel. And after this revision, the accuracy of the output became better and can compete with the results on PC.