search

gyandeep8693 / javacv

Automatically exported from code.google.com/p/javacv
GNU General Public License v2.0
0 stars 0 forks source link

libtbb.so not found or crash in avcodec_register_all() on Android with Tegra 2 #366

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Using any Android device with Tegra 2 (e.g. Motorola Xoom, Lenovo K1) 
instantiate a new FrameGrabber instance on a background thread

What is the expected output? What do you see instead?
error in logcat: libtbb.so not found. Works on all other devices

What version of the product are you using? On what operating system?
Android 3. Motorola Xoom and Lenovo K1 (with Tegra 2 CPUs)

Please provide any additional information below.
Not sure if libtbb is compiled to support Tegra 2, or if this is an issue with 
the CPU itself. Is there a way I can recompile opencv to support this CPU? 
Which architecture is OpenCV compiled for in javacv? Is it arm or arm-v7a?

Original issue reported on code.google.com by su...@idearebel.com on 25 Sep 2013 at 4:20

GoogleCodeExporter commented 9 years ago 
The log actually says
Error trying to load libtbb.so

Original comment by su...@idearebel.com on 25 Sep 2013 at 4:22

GoogleCodeExporter commented 9 years ago 
It needs ARMv7, but I'm pretty sure Tegra 2 is ARMv7, so I'm not sure what is 
wrong...

Original comment by samuel.a...@gmail.com on 29 Sep 2013 at 12:04

GoogleCodeExporter commented 9 years ago 
I'm also seeing this issue. Haven't nailed down anything yet. Experienced this 
specifically on a Galaxy Tab.

Original comment by dall...@gmail.com on 14 Nov 2013 at 4:27

GoogleCodeExporter commented 9 years ago 
@dallsq Let us know if you figure out what this is all about, thanks!

Original comment by samuel.a...@gmail.com on 17 Nov 2013 at 8:33

GoogleCodeExporter commented 9 years ago 
Full stack:

F/libc    ( 1512): Fatal signal 4 (SIGILL) at 0x5de96cec (code=1)
D/dalvikvm(  192): GC_EXPLICIT freed 788K, 76% free 13754K/56007K, paused 
3ms+9ms
I/DEBUG   (  104): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 
***
I/DEBUG   (  104): Build fingerprint: 
'samsung/GT-P7510/GT-P7510:4.0.4/IMM76D/UELPL:user/release-keys'
I/DEBUG   (  104): pid: 1512, tid: 1529  >>> com.getcharm.beta <<<
I/DEBUG   (  104): signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 5de96cec
I/DEBUG   (  104):  r0 5de96ce7  r1 00000008  r2 5de96ce8  r3 000270b4
I/DEBUG   (  104):  r4 5debdc00  r5 00000008  r6 00000004  r7 000040f1
I/DEBUG   (  104):  r8 b001b868  r9 5debf000  10 0003f000  fp 5de84000
I/DEBUG   (  104):  ip 00000000  sp 5c3ba668  lr b0003a43  pc 5de96cec  cpsr 
00000010
I/DEBUG   (  104):  d0  7ff0000000000000  d1  3ff0000043200000
I/DEBUG   (  104):  d2  437e8000000000fe  d3  000000003f000000
I/DEBUG   (  104):  d4  000001fd00000000  d5  3fe999999999999a
I/DEBUG   (  104):  d6  4040000000000000  d7  3eaaaaab3f800000
I/DEBUG   (  104):  d8  0000000000000000  d9  0000000000000000
I/DEBUG   (  104):  d10 0000000000000000  d11 0000000000000000
I/DEBUG   (  104):  d12 0000000000000000  d13 0000000000000000
I/DEBUG   (  104):  d14 0000000000000000  d15 0000000000000000
I/DEBUG   (  104):  scr 80000010
I/DEBUG   (  104): 
I/DEBUG   (  104):          #00  pc 00012cec  
/data/data/com.getcharm.beta/lib/libtbb.so
I/DEBUG   (  104):          #01  lr b0003a43  /system/bin/linker
I/DEBUG   (  104): 
I/DEBUG   (  104): code around pc:
I/DEBUG   (  104): 5de96ccc e1a00006 eb004a45 eb004b9b 0002745c  
....EJ...K..\t..
I/DEBUG   (  104): 5de96cdc fffffe00 fffffea8 fffffeb0 e59f300c  
.............0..
I/DEBUG   (  104): 5de96cec f2c00010 e79f3003 f443078f e12fff1e  
.....0....C.../.
I/DEBUG   (  104): 5de96cfc 000270b4 e59f300c e79f3003 e2833008  
.p...0...0...0..
I/DEBUG   (  104): 5de96d0c e5803000 e12fff1e 000270a4 e12fff1e  
.0..../..p..../.
I/DEBUG   (  104): 
I/DEBUG   (  104): code around lr:
I/DEBUG   (  104): b0003a20 2301b90a 1e4be004 0483eb00 33fff04f  
...#..K.....O..3
I/DEBUG   (  104): b0003a30 460d009e 6822e006 1e5019a4 d8001cc3  
...F.."h..P.....
I/DEBUG   (  104): b0003a40 3d014790 dcf62d00 bf00bd70 4c05b510  
.G.=.-..p......L
I/DEBUG   (  104): b0003a50 447c2001 f00160e0 2300ffb1 f00160e3  . 
|D.`.....#.`..
I/DEBUG   (  104): b0003a60 bd10ffad 00005aa6 4b1ab51f 22004601  
.....Z.....K.F."
I/DEBUG   (  104): 
I/DEBUG   (  104): memory map around addr 5de96cec:
I/DEBUG   (  104): 5dd84000-5de84000 /dev/ashmem/dalvik-jit-code-cache (deleted)
I/DEBUG   (  104): 5de84000-5debb000 /data/data/com.getcharm.beta/lib/libtbb.so
I/DEBUG   (  104): 5debb000-5debc000 
I/DEBUG   (  104): 
I/DEBUG   (  104): stack:
I/DEBUG   (  104):     5c3ba628  b00094f0  /system/bin/linker
I/DEBUG   (  104):     5c3ba62c  b0009f60  /system/bin/linker
I/DEBUG   (  104):     5c3ba630  00000413  
I/DEBUG   (  104):     5c3ba634  5de90a70  
/data/data/com.getcharm.beta/lib/libtbb.so
I/DEBUG   (  104):     5c3ba638  b0009934  /system/bin/linker
I/DEBUG   (  104):     5c3ba63c  5de84114  
/data/data/com.getcharm.beta/lib/libtbb.so
I/DEBUG   (  104):     5c3ba640  b001c88c  
I/DEBUG   (  104):     5c3ba644  b00094fc  /system/bin/linker
I/DEBUG   (  104):     5c3ba648  b000ffa0  
I/DEBUG   (  104):     5c3ba64c  00000000  
I/DEBUG   (  104):     5c3ba650  b001b868  
I/DEBUG   (  104):     5c3ba654  5debf000  
I/DEBUG   (  104):     5c3ba658  0003f000  
I/DEBUG   (  104):     5c3ba65c  b00040d9  /system/bin/linker
I/DEBUG   (  104):     5c3ba660  df0027ad  
I/DEBUG   (  104):     5c3ba664  00000000  
I/DEBUG   (  104): #00 5c3ba668  b000ffa0  
I/DEBUG   (  104):     5c3ba66c  5debdccc  
/data/data/com.getcharm.beta/lib/libtbb.so
I/DEBUG   (  104):     5c3ba670  0000005b  
I/DEBUG   (  104):     5c3ba674  b0004627  /system/bin/linker
I/DEBUG   (  104):     5c3ba678  00000000  
I/DEBUG   (  104):     5c3ba67c  00000000  
I/DEBUG   (  104):     5c3ba680  0003f0f1  
I/DEBUG   (  104):     5c3ba684  b0003be7  /system/bin/linker
I/DEBUG   (  104):     5c3ba688  b0006cbc  /system/bin/linker
I/DEBUG   (  104):     5c3ba68c  b0006bcc  /system/bin/linker
I/DEBUG   (  104):     5c3ba690  00000000  
I/DEBUG   (  104):     5c3ba694  b000ffa0  
I/DEBUG   (  104):     5c3ba698  b001b97c  
I/DEBUG   (  104):     5c3ba69c  0000005b  
I/DEBUG   (  104):     5c3ba6a0  000040f1  
I/DEBUG   (  104):     5c3ba6a4  b001b868  
I/DEBUG   (  104):     5c3ba6a8  5debf000  
I/DEBUG   (  104):     5c3ba6ac  0003f000  

Ouput from cat /proc/cpuinfo:

Processor   : ARMv7 Processor rev 0 (v7l)
processor   : 0
BogoMIPS    : 1998.84
processor   : 1
BogoMIPS    : 1998.84
Features    : swp half thumb fastmult vfp edsp vfpv3 vfpv3d16 tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x1
CPU part    : 0xc09
CPU revision    : 0
Hardware    : p3
Revision    : 000e
Serial  : <redacted>

And the native library directory does contain libtbb.so. My assumption is that 
if the architecture isn't supported, the shared library isn't copied over, but 
that's not something I've verified in any capacity.

Original comment by dall...@gmail.com on 18 Nov 2013 at 11:19

GoogleCodeExporter commented 9 years ago 
http://stackoverflow.com/a/17769485/407782 might shed some light

Original comment by dall...@gmail.com on 18 Nov 2013 at 11:22

GoogleCodeExporter commented 9 years ago 
And potentially even better: http://stackoverflow.com/a/7104177/407782

Original comment by dall...@gmail.com on 18 Nov 2013 at 11:23

GoogleCodeExporter commented 9 years ago 
So, based on that feedback and looking at build_ffmpeg-android-arm.sh, the 
problem is likely the args specifying '-mfpu=neon' which is not sure to be 
available on all armv7 implementations.

Original comment by dall...@gmail.com on 19 Nov 2013 at 5:22

GoogleCodeExporter commented 9 years ago 
Ah ah, thanks for the links! The problem isn't `-mfpu=neon`, it's 
`-mfpu=vfpv3-d16`, which seems to be required by Tegra 2. I'll be adding that 
to the default compiler options of JavaCPP and we'll see what that gives...

Original comment by samuel.a...@gmail.com on 24 Nov 2013 at 1:00

GoogleCodeExporter commented 9 years ago 
Cool... I haven't had a chance to attempt any fix yet. If you do recompile, 
please feel free to comment and upload here and I can verify the new build.

Original comment by dall...@gmail.com on 25 Nov 2013 at 3:39

GoogleCodeExporter commented 9 years ago 
Has anybody had any luch with this? I have just tried recompiling ffmpeg, 
replacing both instances of "-mfpu=neon" with "-mfpu=vfpv3-d16" in 
build_ffmpeg-android-arm.sh. I have tested the changes on my Nexus 7(which 
worked before the change and after), and my Galaxy Tab 10.1. I still get the 
"Trying to load lib libtbb.so" error message on my Tab. However, instead of it 
crashing at the very beginning like it used to, it will now at least create a 
1KB mp4 file, then crash.

Original comment by marwf...@gmail.com on 8 Dec 2013 at 9:13

GoogleCodeExporter commented 9 years ago 
All the binaries for the newly released JavaCV 0.7 have been compiled that way, 
so it should fix this issue. Please test it out, and let me know the result, 
thanks!

Original comment by samuel.a...@gmail.com on 7 Jan 2014 at 1:11

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
@jim It looks like something is happening in `avcodec_register_all()` that the 
CPU doesn't like. Can you try to do something with OpenCV as well, such as 
`cvSmooth(image, image, CV_GAUSSIAN, 3)`?

Because the difference between OpenCV and FFmpeg, is that FFmpeg comes with 
NEON instructions, but it's supposed to be able to autodetect when the running 
CPU doesn't support them. It's possible that Tegra 2 doesn't like what FFmpeg 
is doing for that, so we could try to disable everything by rebuilding ffmpeg 
without the "-mfpu=neon" and "--enable-runtime-cpudetect" flags. Let me know 
the result of that, thanks!

Original comment by samuel.a...@gmail.com on 25 Jan 2014 at 1:10

GoogleCodeExporter commented 9 years ago 
Hello,

(following up here after emails to Samuel)

I'm using the JavaCV 0.7 binaries release directly taken from 
http://code.google.com/p/javacv/. None of the devices that I mention here are 
rooted. On my Droid X2, OS 2.3.5, my helloworld app fails at the invocation of 

FFmpegFrameGrabber.tryLoad();

during execution of the (only) onCreate() and (after refactoring) on a button 
press callback methods.

The behaviour of the failure is the android app just dies and no stacktrace is 
shown in logcat. Attached here is the content that gets displayed in Eclipse's 
logcat console.

However on my Nexus 10 and Samsung Galaxy Tab3 7" runs the application fine. 

Droid X2 specs website 
(http://www.phonearena.com/phones/Motorola-DROID-X2_id5235) states that the 
hardware is NVIDIA Tegra 2.

However, in my code when it runs on Nexus 10 successfully I do an 
IplImage.create because I want to rotate the frame and save. For kicks, I 
changed the line

...
IplImage frame2 = IplImage.create(imageWidth, imageHeight, 
opencv_core.IPL_DEPTH_8U, 4);
...

to

...
IplImage frame2 = IplImage.create(imageWidth + 10, imageHeight, 
opencv_core.IPL_DEPTH_8U, 4);
...

to force an exception (or an assertion) from the JNI code and it shows in 
Eclipse's logcat console. Attached is that output. So a stacktrace does show in 
my logcat.

I'm not sure where to look or set up catching something that dies in JNI -- 
other than what logcat shows. Is there documentation for more capturing of a 
failure?

Both the Nexus 10 and Droid X2 (and presumably Tab3 7") give the following 
output of

01-17 07:57:13.427: D/JavaCVOpenCV(17286): Build CPU_ABI:'armeabi-v7a'
01-17 07:57:13.427: D/JavaCVOpenCV(17286): Build CPU_ABI2:'armeabi'
01-17 07:57:13.427: D/JavaCVOpenCV(17286): os.arch:'armv7l'

from executing

         Log.d(Consts.TAG, "Build CPU_ABI:'" + Build.CPU_ABI + "'");
         Log.d(Consts.TAG, "Build CPU_ABI2:'" + Build.CPU_ABI2 + "'");
         Log.d(Consts.TAG, "os.arch:'" + System.getProperty("os.arch") + "'");

FWIW: I'm using Eclipse on Windows 7.

Thanks,
Jim

Original comment by jimathom...@gmail.com on 25 Jan 2014 at 4:30

Attachments:

GoogleCodeExporter commented 9 years ago 
Issue 423 has been merged into this issue.

Original comment by samuel.a...@gmail.com on 6 Feb 2014 at 12:37

GoogleCodeExporter commented 9 years ago 
Sir, If there is no way to figure out how to solve this exception , is it 
possible to atleast add a bit of code to the lib so that the exception can be 
caught in an android application (and then necessary actions taken at the 
android side) . Here is a link about how may be an exception could be covered 
in the jni itself. i am aware that you know better but just for reference as to 
how it might be captured in android then.

http://blog.httrack.com/blog/2013/08/23/catching-posix-signals-on-android/

Since, once the fatal signal error occurs, there is no exception that is thrown 
for the same. The cursor just returns, and the application stops.

Thanks .

Original comment by hearbeat...@gmail.com on 7 Feb 2014 at 6:51

GoogleCodeExporter commented 9 years ago 
Sure, it sounds useful enough.

If anyone feels like implementing that so we can include it in future versions 
of JavaCPP, let me know! Thanks

Original comment by samuel.a...@gmail.com on 7 Feb 2014 at 11:00

GoogleCodeExporter commented 9 years ago 
I ran "strings" on libavformat.so and got a list of compiler flags.  I see 
-mfpu=vfpv3-d16 there but you're still using -mfpu=neon.  I tried building 
FFmpeg without -mfpu=neon and it worked on my tegra 2 device (a Galaxy Tab 
10.1).  I only tested FFmpeg though, not OpenCV.

Original comment by pfals...@gmail.com on 26 Feb 2014 at 11:17

GoogleCodeExporter commented 9 years ago 
A little more background.  I had some code that was using JavaCV to use some 
FFmpeg classes (and one OpenCV class, IplImage).  Since libtbb.so was crashing, 
and was only referenced by OpenCV, I tried rewriting my code so that it only 
uses FFmpeg and not any of the OpenCV classes.  That caused my app to crash in 
libavformat.so instead.  So I had to try recompiling FFmpeg with different 
compiler flags and that worked.

Original comment by pfals...@gmail.com on 26 Feb 2014 at 11:23

GoogleCodeExporter commented 9 years ago 
@pfalstad Thanks for trying this out! According to GCC's documentation, though, 
"-mfpu=neon" doesn't actually do anything. It's absence is only supposed to 
prevent the coder from using NEON intrinsics. But according to your tests, this 
isn't the case, is this correct?

If you find more info about that and its interaction with "-mfpu=vfpv3-d16", 
please let us know, thanks!

Original comment by samuel.a...@gmail.com on 2 Mar 2014 at 6:28

GoogleCodeExporter commented 9 years ago 
I tried building one of the files (libavformat/mux.c) with -S, with and without 
-mfpu=neon, and it definitely generates different code.  Here's part of a diff. 
 It's using neon instructions like vdup and vshr.

--- mux.s.neon  2014-03-02 08:48:14.000000000 -0600
+++ mux.s.noneon        2014-03-02 08:47:46.000000000 -0600
@@ -1,6 +1,6 @@
        .arch armv7-a
        .eabi_attribute 27, 3
-       .fpu neon
+       .fpu vfpv3-d16
        .eabi_attribute 20, 1
        .eabi_attribute 21, 1
        .eabi_attribute 23, 3
@@ -204,18 +204,18 @@
 .LVL21:
 .L15:
 .LBB25:
-       .loc 1 663 0
-       ldr     r0, [sp, #32]
-.LVL22:
        .loc 1 664 0
-       vdup.8  d16, fp
+       uxtb    r0, fp
+.LVL22:
+       mov     r1, #0
+       strd    r0, [sp, #72]
        .loc 1 663 0
        mov     r1, #0
+       ldr     r0, [sp, #32]
        ldr     r2, [r10, #40]
 .LVL23:
        .loc 1 664 0
-       vshr.u64        d16, d16, #56
-       fstd    d16, [sp, #72]  @ int
+       ldr     r3, [r9, #40]
        .loc 1 663 0
        uxtb    r0, r0
        strd    r0, [sp, #64]

Original comment by pfals...@gmail.com on 2 Mar 2014 at 2:56

GoogleCodeExporter commented 9 years ago 
Ok, that's interesting. I don't remember having trouble running that code on a 
non-NEON-enabled but otherwise ARMv7 CPU that was not Tegra 2. I don't have a 
Tegra 2 here, so I cannot try it out, but if you could figure out a set of 
flags that would let FFmpeg use NEON when it's available, but still run on 
Tegra 2 without NEON, I would very much like to know.

Thanks for all the help!

Original comment by samuel.a...@gmail.com on 2 Mar 2014 at 3:06

GoogleCodeExporter commented 9 years ago 
It does not appear possible to support both NEON and Tegra 2 with the same 
binary:

"-mfpu=neon selects VFPv3 with NEON coprocessor extensions."
http://doc.ironwoodlabs.com/arm-arm-none-eabi/html/getting-started/sec-armfloat.
html

"Building for -mfpu=neon means Marvell, nVidia are left out."
https://wiki.debian.org/ArmHardFloatPort/VfpComparison

So, what do you guys think? Should we distribute something that runs on all 
ARMv7 CPU, including Tegra 2? Or should we distribute binaries that take 
advantage of NEON instructions? It seems like we can get over 2x speedup in 
some applications:
http://androidtools.squarespace.com/share/Light%20up%20you%20Apps%20with%20NEON.
pdf

Original comment by samuel.a...@gmail.com on 3 Mar 2014 at 7:28

GoogleCodeExporter commented 9 years ago 
Ok, starting from JavaCV 0.8, I'm building everything with "-mfpu=vfpv3-d16" 
and without "-mfpu=neon", so that should fix this issue. This new version also 
comes with easier to use build scripts, so please take advantage of that to try 
out different sets of options to satisfy your needs.

A lot of other things have changed with this new version, so please make sure 
to read the news release here:
    http://bytedeco.org/release/2014/04/28/first-release.html

Incidentally, the project is now hosted on GitHub:
    https://github.com/bytedeco/javacv

Thanks for all your help on this issue!

Original comment by samuel.a...@gmail.com on 29 Apr 2014 at 1:06

GoogleCodeExporter commented 9 years ago 
I have tried using a Samsung GT-P7500 with Nvidia Tegra 2 and the app crashes 
(it's the only device it can't load the lib correctly). I leave you the logcat 
file attached. I don't know if it's related but the .so library is located 
under: /main/jniLibs/armeabi-v7a with Android Studio 0.8.2.

Do I have to compile everything with "-mfpu=vfpv3-d16"?

Thanks.

Original comment by alde...@gmail.com on 14 Jul 2014 at 10:37

Attachments:

GoogleCodeExporter commented 9 years ago 
Oh I didn't remember to put my GYP_DEFINES:
    export GYP_DEFINES="OS=android host_os=linux target_arch=arm libjingle_java=1 build_with_libjingle=1 build_with_chromium=0 enable_tracing=1 arm_neon=1 armv7=1 enable_android_opensl=1"

Does arm_neon=1 affect? If I put arm_neon=0, will it work?

Original comment by alde...@gmail.com on 14 Jul 2014 at 10:52

GoogleCodeExporter commented 9 years ago 
Issue 423 has been merged into this issue.

Original comment by samuel.a...@gmail.com on 6 Dec 2014 at 11:37

GoogleCodeExporter commented 9 years ago 
Issue 423 has been merged into this issue.

Original comment by samuel.a...@gmail.com on 11 Dec 2014 at 7:24