iOS app crashes 1 out of 100 times with EXC_BAD_ACCESS KERN_INVALID_ADDRESS, using the same Native method

Question

iOS app crashes 1 out of 100 times with EXC_BAD_ACCESS KERN_INVALID_ADDRESS, using the same Native method

Toine de Boer 1

My bound native iOS library method crashes 1 out of 100 times, when the native library is doing a memmove on a ‘short[] data’.
Its from a Xamarin.Ios project that has a bound method for a native iOS library that is using a ‘short[] data’ as input.

Can it be that the ‘short[] data’ is corrupted, cleaned or whiped by .Net runtime in any way?
(when running the native method nothing is done in .Net code with the ‘short[] data’)
Can I make the ‘short[] data’ more save, that the Native code just has a copy of the .Net version?

The bound method looks like this:

[DllImport("__Internal")]
public static extern unsafe int ps_process_raw(ps_decoder_t* ps, short[] data, nuint n_samples, int no_search, int full_utt);

Firebase Crashlytics shows a crash in its log, but the App won’t really crash but just does not return the Method…so the app wont crash and the Native library is still usable after the crash that’s not really a crash.

Crashlytics show this:

“EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x000000010df00000”.
Stacktrace:
Crashed: Thread Pool Worker
0 libsystem_platform.dylib 0x1e5a946b0 _platform_memmove + 176
1 MyApp.Ios 0x1024ab694 fe_shift_frame + 52844

Any help or suggestions would be very much appreciated.

Wenyan Zhang (Shanghai Wicresoft Co,.Ltd.) 36,436 Reputation points Microsoft External Staff

2021-09-01T03:23:52.323+00:00

EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x000000010df00000

means that you attempt to access an deallocated object, 0x000000010df00000 is invalid. I'm afraid short[] data has been deallocated.
Toine de Boer 1 Reputation point

2021-09-01T09:15:51.56+00:00
Thanks for your reply.

It indeed looks like there is something going wrong with the ‘short[] data’, but I’m not sure what because almost nothing happens with the array before the memmove is done and sometimes crashes.

So I’m looking for more insights on how data goos from the .Net to Native environments, can't find much specifics on this topic.
Looking for info like:

Is de data copied between runtimes/environments? or does it use/work with the same data location in memory?

Can Native data in memory (coming from .Net) be cleaned automatically by the runtime?

What are the cathes working with async Tasks invoking Native methods?

Can you force Tasks to always work from the same (not UI) thread?

With this better understanding I can make the code/data more safe while working in a .Net unsafe environment.
Wenyan Zhang (Shanghai Wicresoft Co,.Ltd.) 36,436 Reputation points Microsoft External Staff

2021-09-02T07:39:42.71+00:00

For your first question, this is similar to managed code in that value types will be passed by value (unless in, out, or ref is used), and reference types will pass a pointer, so the short[] would not be copied to unmanaged memory.
Second, the .NET/Mono runtime should not be collecting or doing anything with unmanaged memory, which is why it is called unmanaged. However in a COM environment, the COM environment will do some unmanaged memory handling, but COM is largely a Windows only construct.
Third, the catches are the same. Make sure any managed types that are being used on the native side stay alive until they are certain to not be needed anymore.
Last, If you call ConfigureAwait(false) on a task then the task will stay on the same thread rather than getting marshalled back to the calling thread.
There is no real difference between native interop using P/Invoke [DllImport] on Windows as on iOS as far as memory management is concerned:
https://learn.microsoft.com/en-us/dotnet/standard/native-interop/
https://learn.microsoft.com/en-us/dotnet/standard/native-interop/type-marshaling
https://learn.microsoft.com/en-us/dotnet/framework/interop/default-marshaling-for-arrays
Here's a section on keeping managed objects alive:
https://learn.microsoft.com/en-us/dotnet/standard/native-interop/best-practices#keeping-managed-objects-alive
Toine de Boer 1 Reputation point

2021-09-02T09:46:15.07+00:00

Thanks again WenyanZhang for the explanations.

This way I can rule things out a lot quicker, knowing how it works under the hood.

However, my wording has caused confusion on the last point.
I wasn't trying to refer to Tasks that returned from other treads, keeping them on its current or returning to the calling thread, but I was trying to find a way how do multiple Tasks on the same thread....over a period of time.....if thats possible.

Because I wan't to try to put all my calls for this specific Task todo on the same thread..always.
Just a tryout to watch if I can get the Task more stable this way.

Is there a way to guarantee a Task is handled on the same thread, all the time (not the UI Thread of course) ?
Wenyan Zhang (Shanghai Wicresoft Co,.Ltd.) 36,436 Reputation points Microsoft External Staff

2021-09-03T01:43:57.51+00:00

E.g:
// in button click handler (async void OnButtonClick(…)) on UI thread, calling:
var x = await SomeMethodAsync(); // Runs on it's own thread
var y = 42; // Will run on UI thread

In contrast:
// in button click handler on UI thread, calling:
var x = await SomeMethodAsync().ConfigureAwait(false); // Runs on it's own thread
var y = 42; // Will run on same thread that SomeMethodAsync ran on.
Toine de Boer 1 Reputation point

2021-09-03T08:28:05.403+00:00

Thanks again, I do understand the async/await principles.

I was more looking at a threading topic like this:
https://stackoverflow.com/questions/49043257/how-to-ensure-to-run-some-code-on-same-background-thread

Your answer

Wenyan Zhang (Shanghai Wicresoft Co,.Ltd.) 36,436 Reputation points Microsoft External Staff

2021-09-01T03:23:52.323+00:00

EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x000000010df00000

means that you attempt to access an deallocated object, 0x000000010df00000 is invalid. I'm afraid short[] data has been deallocated.
Toine de Boer 1 Reputation point

2021-09-01T09:15:51.56+00:00

Thanks for your reply.

It indeed looks like there is something going wrong with the ‘short[] data’, but I’m not sure what because almost nothing happens with the array before the memmove is done and sometimes crashes.

So I’m looking for more insights on how data goos from the .Net to Native environments, can't find much specifics on this topic.
Looking for info like:

Is de data copied between runtimes/environments? or does it use/work with the same data location in memory?

Can Native data in memory (coming from .Net) be cleaned automatically by the runtime?

What are the cathes working with async Tasks invoking Native methods?

Can you force Tasks to always work from the same (not UI) thread?

With this better understanding I can make the code/data more safe while working in a .Net unsafe environment.
Wenyan Zhang (Shanghai Wicresoft Co,.Ltd.) 36,436 Reputation points Microsoft External Staff

2021-09-02T07:39:42.71+00:00

For your first question, this is similar to managed code in that value types will be passed by value (unless in, out, or ref is used), and reference types will pass a pointer, so the short[] would not be copied to unmanaged memory.
Second, the .NET/Mono runtime should not be collecting or doing anything with unmanaged memory, which is why it is called unmanaged. However in a COM environment, the COM environment will do some unmanaged memory handling, but COM is largely a Windows only construct.
Third, the catches are the same. Make sure any managed types that are being used on the native side stay alive until they are certain to not be needed anymore.
Last, If you call ConfigureAwait(false) on a task then the task will stay on the same thread rather than getting marshalled back to the calling thread.
There is no real difference between native interop using P/Invoke [DllImport] on Windows as on iOS as far as memory management is concerned:
https://learn.microsoft.com/en-us/dotnet/standard/native-interop/
https://learn.microsoft.com/en-us/dotnet/standard/native-interop/type-marshaling
https://learn.microsoft.com/en-us/dotnet/framework/interop/default-marshaling-for-arrays
Here's a section on keeping managed objects alive:
https://learn.microsoft.com/en-us/dotnet/standard/native-interop/best-practices#keeping-managed-objects-alive
Toine de Boer 1 Reputation point

2021-09-02T09:46:15.07+00:00

Thanks again WenyanZhang for the explanations.

This way I can rule things out a lot quicker, knowing how it works under the hood.

However, my wording has caused confusion on the last point.
I wasn't trying to refer to Tasks that returned from other treads, keeping them on its current or returning to the calling thread, but I was trying to find a way how do multiple Tasks on the same thread....over a period of time.....if thats possible.

Because I wan't to try to put all my calls for this specific Task todo on the same thread..always.
Just a tryout to watch if I can get the Task more stable this way.

Is there a way to guarantee a Task is handled on the same thread, all the time (not the UI Thread of course) ?
Wenyan Zhang (Shanghai Wicresoft Co,.Ltd.) 36,436 Reputation points Microsoft External Staff

2021-09-03T01:43:57.51+00:00

E.g:
// in button click handler (async void OnButtonClick(…)) on UI thread, calling:
var x = await SomeMethodAsync(); // Runs on it's own thread
var y = 42; // Will run on UI thread

In contrast:
// in button click handler on UI thread, calling:
var x = await SomeMethodAsync().ConfigureAwait(false); // Runs on it's own thread
var y = 42; // Will run on same thread that SomeMethodAsync ran on.
Toine de Boer 1 Reputation point

2021-09-03T08:28:05.403+00:00

Thanks again, I do understand the async/await principles.

I was more looking at a threading topic like this:
https://stackoverflow.com/questions/49043257/how-to-ensure-to-run-some-code-on-same-background-thread

Share via

iOS app crashes 1 out of 100 times with EXC_BAD_ACCESS KERN_INVALID_ADDRESS, using the same Native method

Your answer