I’m expecting this to be related to the androidmedia plugin. Can you change gstreamer_android-1.0.c (in share/gst-android/ndk-build) to have gst_debug_set_threshold_from_string("2,amc*:6", TRUE); after the gst_debug_set_default_threshold() call, then rebuild your application, run it and get the complete output on "adb logcat"?

Or alternatively change gst_debug_set_default_threshold() to GST_LEVEL_DEBUG.

I added gst_debug_set_threshold_from_string("2,amc*:6", TRUE);
and i changed the threshold to debug, but the logcat output looks the same.

Can you check if there's anything else in gstreamer_android-1.0.c.in (note the .in!, you need to change the file with the .in at the end) or in your application that calls one of those two functions?

I added a Log next to the Threshold function, but i dont get that Output on logcat! I looked at the web if more Devs have that Problem and maybe there is a Problem with the combination of Android Version + NDK_Toolchain. Here my source:

https://code.google.com/p/android/issues/detail?id=43819

Sounds like Google did something wrong!!!

Do you are able to Test your Tutorial-3 with an Smartphone that runs Android 4.0.3 or lower? Would be nice to know, if you can get this to run!

What makes you think this is the same issue? Adding some more android log output to the beginning of the init function in gstreamer_android-1.0.c.in also does not show up in the logs?

I don't have any device here with Android 4.0.3 or lower, the oldest I have here is 4.2.2.

Okay, i added an log Output at the beginning of the init function and the android_init function, but both will not be called.

Will be one of these function called, when i call System.loadlibrary("gstreamer_android") ?? I dont know about the JNI loading procedure, this is why i'm asking!!

JNI_OnLoad() will be called when System.loadLibrary() is called. Maybe you could put a call to abort() in there and see if your application just exits.

The android_init() function is called as part of GStreamer.init().

I added a return 0; to the JNI_OnLoad and it stucks always. I deleted the line in Android.mk where the plugins will be added and tested it again. The lib will be loaded, so the "return=0;" will be not called. In case of that, i think these changes in the ".c.in" file have no effect. Could that be, that dependencies to other lib from android are not available because of old android Version?

I guess this then needs someone to run everything in gdb on an old Android version to see where exactly it gets stuck when loading the library. It doesn't look like a problem on our side, more something wrong with what the NDK produces... it apparently doesn't even call into our code.


If another library would be missing, it would immediately fail loading.

I've tried the same Task with the Emulator and i got the same results. On API-10 it will be not loaded and on API-22 it now returns Zero -> init will be called!!

So it is definitly a Problem of Googles NDK and this will be not easy to determine where it comes from!!

Btw: The Test with the API-10 Emulator throws out some debug informations, but there were only some Memory addresses. Maybe you can run it by yourself.

Created attachment 310569 [details]
Adb Logcat Output in Debug mode

That's a different problem, right?

I cant figure out where it comes from. Your code is right, because the same build runs on newer Android Versions. I looked for older NDK Releases, but with ndk_r8b i cant compile, because ld is missing. I Looks like that Google does not recognize that they have to fix such bugs. I think they are so fast with releasing newer Version of Android to force People to discard their old smartphones. I my case, i only enable Gstreamer at Android Jellybean. So this will be a non solved bug issue. 

Did you ever get your Framework run on such old Android Versions???

Yes, but that was with older NDKs and quite a while ago. The earliest supported version is supposed to be 2.3.3 (API version 9). We don't use any newer APIs (unconditionally), so if that doesn't work it's most likely a problem with the NDK.

I tested it, and it is a Problem with the NDK!!!

Hey,

i found a little bit time to check for the stuck problem! I used the remote gdbserver to check where the problem comes from! But in my case, gdb just put out the address where the mistakes happen, not more!

Would it be possible for you just to open an Android Emulator with API level 15 or lower, to check why the libgstreamer_android.so will not be loaded! 

You say it works with Android 2.3, but it doesn't!

Thx for Help

If you just have the address, you can use addr2line to translate it to a symbol/line number. That also works for the addresses in the backtrace of "adb logcat". You just have to do it with exactly the .so that you're running.

This is now my GDB Output! But i cant figure out the problem from linker!

GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
0x4006f5e0 in epoll_wait ()
   from C:\Daten\Developing\Examples\GStreamer\android-tutorial-3\obj\local\arme                               abi\libc.so
(gdb) c
Continuing.

Program received signal SIGABRT, Aborted.
0xb00018a0 in ?? ()
   from C:\Daten\Developing\Examples\GStreamer\android-tutorial-3\obj\local\armeabi\linker
(gdb)

Okay, i think i have something!

i started to compile the Tutorial-3 with older versions of GStreamer!

Because of the old version i was forced to use the ndk-r9 and not the new r10e.

All Versions are tested with the armeabi debug version and Android API 15 Smartphone!

These is my list of working GStreamer versions:

1.2.3  working
1.3.90 working
1.3.91 working
1.4.0  working
1.4.1  working
1.4.3  working
1.4.4  not working
1.4.5  not working

1.5.90 not working (r10e)
1.6.0  not working (r10e)

So maybe you can find the mistake in the difference between Version 1.4.3 and 1.4.4.

Would be very nice if you could fix that!

PS: At Android API 18 all works fine...

Okay now my app runs completely on API 10, but with Version 1.4.3.

So there should be some Bug inside of GStreamer Version 1.4.4 and above!!

There was no relevant change to Android specific bits between 1.4.3 and 1.4.4. In any case, it would be good if you could get a proper backtrace.

Run your application with ndk-gdb please :)

This is what i got!

Program received signal SIGABRT, Aborted.
0xb00018a0 in ?? ()
   from C:\Daten\Developing\Examples\GStreamer\android-tutorial-3\obj\local\armeabi\linker
(gdb) backtrace

+ Trace 235949

Is your native Code stripped from debugging symbols and optimized?

Please compile without optimizations or at least include debugging symbols.

In Android.mk LOCAL_CFLAGS += -DLINKER_DEBUG=1
In Application.mk: App_OPTIM := debug
In NDK-Builder Env.Variable NDK_DEBUG = 1
an at least in AndroidManifest.xml debuggable="true"

These are the Options i had for the last Backtrace on the Comment before!

But at least i think there is some Deadlocking, because the System.loadlibrary("gstreamer_android") will never return and it is also wrapped by a try/catch block with no reaction!

Maybe you have time and you could generate an APK of Tutorial-5 for your 4.2.2 Android Smartphone with GStreamer armeabi Version 1.6.0 from your download site and see if it does the same!

I tested it with API 17 Android 4.2.2 and it works!! So you dont have to test

This is the last what i found what could be the Problem:

https://code.google.com/p/android/issues/detail?id=43819

From here know my Hands are tied!

I can't say where the failure is but i removed a lot of not needed plugins in the plugins.mk and now GStreamer runs on all Android versions.

Here is my used plugins list: (i use flashvideo and hls-stream)

GSTREAMER_PLUGINS_CORE := coreelements adder app audioconvert audiorate audioresample typefindfunctions videoconvert videorate videoscale volume autodetect
GSTREAMER_PLUGINS_PLAYBACK := playback
GSTREAMER_PLUGINS_SYS := opensles opengl
GSTREAMER_PLUGINS_NET := tcp rtsp rtp rtpmanager soup udp dataurisrc sdp srtp
GSTREAMER_PLUGINS_CODECS_RESTRICTED := mpegtsdemux mpegtsmux voaacenc mad mpeg2dec realmedia x264 libav
GSTREAMER_PLUGINS_CODECS := fragmented dashdemux audioparsers auparse dv flac flv flxdec multipart speex taglib openh264 opus videoparsersbad

The rest of the plugin topics are not linked in Android.mk!

So there is in one or more plugins some linker failure!

Does it hang again if you add the androidmedia plugin?

I've added the androidmedia plugin to my plugins list and it works properly!

I don't know which of the plugins is the guilty one. I erased 4-6 plugins each stage to get my list.

After removing which did it start to work? Let's try to find the offending plugin

Sorry, 

this is too much work for me! You have my list which works with the API 10 Android (2.3). 

Take Eclipse with your Tutorial-3 Project and add each missing plugin from my list, compile and test it with the Android Emulator!

At least i did enough to find out why it stucks everytime!

I also had this problem on an Android 4.0.3 device but not on a 5.1.1 device.
It went away after removing some plugins from plugins.mk.

Someone with the problem would have to run the application in a debugger and get a backtrace of all threads when it hangs.

Created attachment 328688 [details]
BackTrace JAVA

Code at com.gst_sdk_tutorials.tutorial_5.Tutorial5.<clinit>(Tutorial5.java:289):
System.loadLibrary("gstreamer_android");

Created attachment 328689 [details]
BackTrace NATIVE

I also took the time to check which plugins cause the hang seen in the backtraces I just added.

If you remove the plugins "pango" and "rsvg" (both of them) from plugins.mk, the problem does not occur any more.

I checked this using gstreamer version 1.8.1 armv7:
https://gstreamer.freedesktop.org/data/pkg/android/1.8.1/gstreamer-1.0-android-armv7-1.8.1.tar.bz2


Android version: 4.0.3

So this is Android's own code that is locking up here:
https://android.googlesource.com/platform/ndk/+/master/sources/android/cpufeatures/cpu-features.c#522

dlopen() of libc.so is where it stops. Not sure what we can do about that.

And yes, disabling anything that uses cairo/pixman will help as IIRC that's the only place where we call that.

Do cairo/pixman still use that codepath ? Re-assign to cerbero since it seems to be an issue in the dependencies.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/cerbero/issues/19.