Bug 13460 - Android 4.3 incompatible
Summary: Android 4.3 incompatible
Status: VERIFIED FIXED
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler ()
Version: 4.8.x
Hardware: PC Windows
: Highest normal
Target Milestone: ---
Assignee: Alex Rønne Petersen
URL:
: 13516 13857 13896 ()
Depends on:
Blocks:
 
Reported: 2013-07-25 04:29 UTC by Luzanne
Modified: 2014-07-28 16:05 UTC (History)
12 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
VERIFIED FIXED

Description Luzanne 2013-07-25 04:29:35 UTC
Posted this issue also on the forums:
http://forums.xamarin.com/discussion/6340/android-4-3-incompatible#latest

I'm using the latest Xamarin.Android, 4.8.00013 (3f1c339b) with Visual Studio 2010 on w7 64b.
My device is a Galaxy Nexus with Android 4.3 (image flashed from official Google images)

This error can reproduced by creating a new project and debug that app.



Get the following error when deploying and debugging an app:

07-25 10:11:49.833 D/dalvikvm( 1253): Late-enabling CheckJNI
Loaded assembly: /data/data/com.xxx.development/files/.__override__/xxx.dll
07-25 10:11:50.067 D/dalvikvm( 1253): Trying to load lib /data/app-lib/com.xxx.development-1/libmonodroid.so 0x42156a70
07-25 10:11:50.067 D/dalvikvm( 1253): Added shared lib /data/app-lib/com.xxx.development-1/libmonodroid.so 0x42156a70
07-25 10:11:50.138 W/MonoDroid-Debugger( 1253): Accepted stdout connection: 41
Loaded assembly: /data/data/com.xxx.development/files/.__override__/xxx.dll
07-25 10:11:50.903 W/libc    ( 1253): WARNING: generic atexit() called from legacy shared library
07-25 10:11:51.567 W/monodroid-gc( 1253): GREF GC Threshold: 46800
Loaded assembly: Mono.Android.Support.v4.dll [External]
Loaded assembly: Mono.Android.GoogleMaps.dll [External]
Loaded assembly: Mono.Android.dll [External]
In mgmain JNI_OnLoad
07-25 10:11:51.794 F/libc    ( 1253): bionic/libc/upstream-netbsd/libc/stdlib/bsearch.c:70: bsearch: assertion "key != NULL" failed
07-25 10:11:51.794 E/mono-rt ( 1253): Stacktrace:
07-25 10:11:51.794 E/mono-rt ( 1253): 
07-25 10:11:51.794 E/mono-rt ( 1253): 
07-25 10:11:51.794 E/mono-rt ( 1253): =================================================================
07-25 10:11:51.794 E/mono-rt ( 1253): Got a SIGSEGV while executing native code. This usually indicates
The program 'Mono' has exited with code 255 (0xff).
07-25 10:11:51.794 E/mono-rt ( 1253): used by your application.
07-25 10:11:51.794 E/mono-rt ( 1253): =================================================================
07-25 10:11:51.794 E/mono-rt ( 1253):
Comment 1 Jonathan Pryor 2013-07-25 07:39:41 UTC
Quick grep of the Mono source, the following files use bsearch() with possibly-null `key` values. (Other locations either null-check the key in the same function or use a value which can't possibly be null.)

mono/metadata/class.c
mono/metadata/debug-mono-symfile.c
mono/metadata/icall.c
mono/metadata/locales.c
Comment 2 Jonathan Pryor 2013-07-25 10:24:41 UTC
Related: Android's bsearch() function comes from NetBSD, which indeed asserts that `key` is not null:

https://github.com/android/platform_bionic/blob/master/libc/upstream-netbsd/libc/stdlib/bsearch.c#L70
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/stdlib/bsearch.c?rev=1.15&content-type=text/x-cvsweb-markup&only_with_tag=MAIN

WHY NetBSD asserts that `key` is not null, I have no idea.

The UNIX standard does not appear to have that requirement: http://pubs.opengroup.org/onlinepubs/9699919799/functions/bsearch.html

Likewise, in my interpretation of my copy of the ANSI/ISO C99 standard bsearch() does not require that `key` be not null; in particular §7.20.5 ¶2 states:

> The implementation shall ensure that the second argument of the
> comparison function (when called from bsearch)... 
> are pointers to elements of the array.254) The first argument when 
> called from bsearch shall equal key.

This implies that `key` can reside outside of the array, and NULL would certainly be outside of the array...
Comment 3 Jonathan Pryor 2013-07-25 10:26:39 UTC
NetBSD bsearch.c revision 1.10 added the `key` assert:

http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/stdlib/bsearch.c?rev=1.10&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
Comment 4 Jonathan Pryor 2013-07-25 10:44:49 UTC
alexrp: looks like the quickest/sanest fix will be to add a bsearch()-like function to eglib or mono proper and use that instead of bsearch(3).
Comment 5 Jonathan Pryor 2013-07-26 17:20:56 UTC
Fixed in mono/bd54b2b7, monodroid/monodroid-4.8.0-branch/39e2ccd2 for XA 4.8.1.

Fixed in monodroid/a93d13b7 for XA 4.8.2.
Comment 6 Lucian POPESCU 2013-07-29 04:29:03 UTC
Hi,
Is there an update available for download?

Thank you,
Lucian
Comment 7 Jonathan Pryor 2013-07-29 10:31:06 UTC
*** Bug 13516 has been marked as a duplicate of this bug. ***
Comment 8 Jonathan Pryor 2013-08-15 14:09:43 UTC
*** Bug 13896 has been marked as a duplicate of this bug. ***
Comment 9 Prashant manu 2014-01-21 08:39:50 UTC
I have chec ked this issue with following builds:

All Windows
X.S 4.2.3(build 146)
X.Android 4.13.0-4

I am successfully able to deploy and launch application on device in both debug and release mode.

Device info:
Samsung S4 version 4.3
Comment 10 Jonathan Pryor 2014-07-28 16:05:05 UTC
*** Bug 13857 has been marked as a duplicate of this bug. ***