Select to view content in your preferred language

FATAL 11 when trying to get Features Table from Geodatabase

865
2
05-31-2018 11:34 AM
NathanWestfall1
Occasional Contributor

From time to time, I get in our Xamarin.Android app a fatal 11 when loading a features table.

Here is the C# code

public static Esri.ArcGISRuntime.Data.GeodatabaseFeatureTable GetStreetFeatureTable(Esri.ArcGISRuntime.Data.Geodatabase gdb, string tableName)
{
    GeodatabaseFeatureTable table = gdb.GeodatabaseFeatureTable(tableName);

    if (table == null)
    {
        table = gdb.GeodatabaseFeatureTable(0);
    }

    return table;
}

Here's the crash

--------- beginning of crash

05-31 09:26:13.559 23763 23991 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 23991 (Thread-3804)

05-31 09:26:13.616 162 162 I DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

05-31 09:26:13.616 162 162 I DEBUG : Build fingerprint: 'Android/:eng/release-keys'

05-31 09:26:13.616 162 162 I DEBUG : Revision: '0'

05-31 09:26:13.616 162 162 I DEBUG : ABI: 'arm'

05-31 09:26:13.616 162 162 I DEBUG : pid: 23763, tid: 23991, name: Thread-3804 >>> APK_NAME <<<

05-31 09:26:13.616 162 162 I DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x8

05-31 09:26:13.626 162 162 I DEBUG : r0 ba96dbe8 r1 00000000 r2 8ddff4a0 r3 bac3c718

05-31 09:26:13.626 162 162 I DEBUG : r4 00000000 r5 ba95f950 r6 00000000 r7 00000000

05-31 09:26:13.626 162 162 I DEBUG : r8 00000000 r9 ba96dbe8 sl 8ddff4dc fp ba9a8208

05-31 09:26:13.626 162 162 I DEBUG : ip 9947cefd sp 8ddff448 lr 9855df11 pc 9855dec4 cpsr 800f0030

05-31 09:26:13.626 162 162 I DEBUG :

05-31 09:26:13.626 162 162 I DEBUG : backtrace:

05-31 09:26:13.626 162 162 I DEBUG : #00 pc 0089aec4 /data/app/APK/lib/arm/libruntimecore.so

05-31 09:26:13.626 162 162 I DEBUG : #01 pc 0089af0d /data/app/APK/lib/arm/libruntimecore.so

05-31 09:26:13.626 162 162 I DEBUG : #02 pc 0089b177 /data/app/APK/lib/arm/libruntimecore.so

05-31 09:26:13.626 162 162 I DEBUG : #03 pc 00741ffb /data/app/APK/lib/arm/libruntimecore.so (RT_Geodatabase_getGeodatabaseFeatureTables+50)

05-31 09:26:13.626 162 162 I DEBUG : #04 pc 000d6fd7 /data/app/APK/lib/arm/libRuntimeCoreNet.so (CoreRT_Geodatabase_getGeodatabaseFeatureTables+26)

05-31 09:26:13.626 162 162 I DEBUG : #05 pc 0000e944 <unknown>

And here is the build enviroment

Visual Studio 15.7.1
Xamarin 4.10.0.442
Xamarin.Android SDK 8.3.0.19
JDK 1.8.0_172 (32 bit version)
Android SDK Tools 25.2.5
Android SDK Platform-tools 27.0.1
Android SDK Build-tools 25.0.3, 23.0.3
SDK Platforms Installed
8.0 (API 26)
7.1.1 (API 25)
6.0 (API 23)

Esri Runtime 100.2.1

The only thing I can think of that I might be able to prevent, is calling this function from 2 threads at the same time.  We have different feature layers we use and it is possible that from time to time two threads could call it at the same time.  

0 Kudos
2 Replies
NathanWestfall
New Contributor
Here's another recent crash

--------- beginning of crash  06-11 14:15:32.688 16446 16669 F libc    : Fatal signal 7 (SIGBUS), code 1, fault addr 0x1b in tid 16669 (app.name)  06-11 14:15:32.796   153   153 I DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***  06-11 14:15:32.796   153   153 I DEBUG   : Build fingerprint: 'Android:eng/release-keys'  06-11 14:15:32.796   153   153 I DEBUG   : Revision: '0'  06-11 14:15:32.796   153   153 I DEBUG   : ABI: 'arm'  06-11 14:15:32.796   153   153 I DEBUG   : pid: 16446, tid: 16669, name: app.name >>> app.name <<<  06-11 14:15:32.796   153   153 I DEBUG   : signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0x1b  06-11 14:15:32.819   153   153 I DEBUG   :     r0 0000001b  r1 b92d4894  r2 b9dc5b4c  r3 b6e065f1  06-11 14:15:32.819   153   153 I DEBUG   :     r4 00000020  r5 b96c61f8  r6 b9982c0c  r7 b9c16ae8  06-11 14:15:32.819   153   153 I DEBUG   :     r8 b96c6278  r9 b9c16af0  sl 8dedfabc  fp 8dedfab8  06-11 14:15:32.819   153   153 I DEBUG   :     ip 8dedf828  sp 8dedf898  lr 98c2ff4b  pc 98c2e520  cpsr 000f0030  06-11 14:15:32.819   153   153 I DEBUG   :   06-11 14:15:32.819   153   153 I DEBUG   : backtrace:  06-11 14:15:32.819   153   153 I DEBUG   :     #00 pc 01051520  /data/app/app.name/lib/arm/libruntimecore.so  06-11 14:15:32.819   153   153 I DEBUG   :     #01 pc 01052f47  /data/app/app.name/lib/arm/libruntimecore.so (_ZNSt6vectorISt8weak_ptrISt8functionIFvN16Esri_runtimecore11Geodatabase8Database21Transaction_operationEEEESaIS8_EE19_M_emplace_back_auxIJSt10shared_ptrIS7_EEEEvDpOT_+98)  06-11 14:15:32.819   153   153 I DEBUG   :     #02 pc 0089ca11  /data/app/app.name/lib/arm/libruntimecore.so  06-11 14:15:32.819   153   153 I DEBUG   :     #03 pc 0089cdb1  /data/app/app.name/lib/arm/libruntimecore.so  06-11 14:15:32.819   153   153 I DEBUG   :     #04 pc 0083215f  /data/app/app.name/lib/arm/libruntimecore.so  06-11 14:15:32.819   153   153 I DEBUG   :     #05 pc 00b05165  /data/app/app.name/lib/arm/libruntimecore.so  06-11 14:15:32.819   153   153 I DEBUG   :     #06 pc 00b05d01  /data/app/app.name/lib/arm/libruntimecore.so  06-11 14:15:32.819   153   153 I DEBUG   :     #07 pc 01774357  /data/app/app.name/lib/arm/libruntimecore.so  06-11 14:15:32.819   153   153 I DEBUG   :     #08 pc 01388405  /data/app/app.name/lib/arm/libruntimecore.so  06-11 14:15:32.819   153   153 I DEBUG   :     #09 pc 01392b17  /data/app/app.name/lib/arm/libruntimecore.so  06-11 14:15:32.819   153   153 I DEBUG   :     #10 pc 01393037  /data/app/app.name/lib/arm/libruntimecore.so  06-11 14:15:32.819   153   153 I DEBUG   :     #11 pc 0139331d  /data/app/app.name/lib/arm/libruntimecore.so  06-11 14:15:32.819   153   153 I DEBUG   :     #12 pc 01392c67  /data/app/app.name/lib/arm/libruntimecore.so  06-11 14:15:32.819   153   153 I DEBUG   :     #13 pc 017de7d3  /data/app/app.name/lib/arm/libruntimecore.so  06-11 14:15:32.819   153   153 I DEBUG   :     #14 pc 0001659b  /system/lib/libc.so (__pthread_start(void*)+30)  06-11 14:15:32.819   153   153 I DEBUG   :     #15 pc 000144c3  /system/lib/libc.so (__start_thread+6) 
0 Kudos
dotMorten_esri
Esri Notable Contributor

it is possible that from time to time two threads could call it at the same time. 

Did you try this with a lock statement to try and prevent it from doing this from multiple threads? Did it help?

Is there any way you can provide us with a reproducer? The above unfortunately doesn't give me much to go on.

0 Kudos