How to decipher a crash call stack #19493
Comments
|
Unfortunately this particular crash (with The most important step is to be able to reproduce the crash locally, and hopefully create a test project. One trick that sometimes make it easier to reproduce is to run the GC in a background thread in a loop, to aggressively free stuff as soon as possible with the idea that it'll crash sooner if something's wrong: static void Main ()
{
var thread = new Thread (() =>
{
while (true) {
Thread.Sleep (1000); // Run GC.Collect every second
GC.Collect ();
Console.WriteLine ("Collected");
}
});
thread.Start ();
UIApplicationMain (...);
}As a sidenote, I'm working on being able to detect this kind of memory corruption issues before they crash the process, and hopefully give better diagnostics, but it will be a while until that's been released. |
This was referenced Nov 30, 2023
rolfbjarne
added a commit
to rolfbjarne/xamarin-macios
that referenced
this issue
Jan 4, 2024
This will hopefully make it easier to diagnose these kinds of crashes:
Thread 0 Crashed:
0 libobjc.A.dylib 0x00000001a6f6e7f8 object_getClass + 48
1 MarketPrimeTool.Net 0x0000000104b90a68 do_icall (interp.c:2273)
2 MarketPrimeTool.Net 0x0000000104b8f838 do_icall_wrapper (interp.c:2361)
3 MarketPrimeTool.Net 0x0000000104b85214 interp_exec_method (interp.c:3885)
4 MarketPrimeTool.Net 0x0000000104b82de8 interp_runtime_invoke (interp.c:2122)
5 MarketPrimeTool.Net 0x0000000104b4aedc mono_jit_runtime_invoke (mini-runtime.c:3650)
6 MarketPrimeTool.Net 0x0000000104a8b874 mono_runtime_try_invoke (object.c:2415)
7 MarketPrimeTool.Net 0x0000000104a8d8a0 mono_runtime_invoke (object.c:2464)
8 MarketPrimeTool.Net 0x0000000104c42b68 native_to_managed_trampoline_68(objc_object*, objc_selector*, _MonoMethod**, objc_object*, unsigned int) (registrar.mm:4511)
9 MarketPrimeTool.Net 0x0000000104c42a00 +[__NSObject_Disposer drain:] (registrar.mm:20968)
10 Foundation 0x00000001adc13b14 __NSThreadPerformPerform + 260
This happens because we try to access freed/invalid memory, but unfortunately
the crash report / stack trace does not contain any hint whatsoever about the
memory that triggered the crash.
By adding an opt-in to validate the memory for a given object, we might be
able to detect this crash in a few cases, and instead throw a managed
exception with much more information.
Ref: dotnet#19493
rolfbjarne
added a commit
to rolfbjarne/xamarin-macios
that referenced
this issue
Jan 5, 2024
This will hopefully make it easier to diagnose these kinds of crashes:
Thread 0 Crashed:
0 libobjc.A.dylib 0x00000001a6f6e7f8 object_getClass + 48
1 MarketPrimeTool.Net 0x0000000104b90a68 do_icall (interp.c:2273)
2 MarketPrimeTool.Net 0x0000000104b8f838 do_icall_wrapper (interp.c:2361)
3 MarketPrimeTool.Net 0x0000000104b85214 interp_exec_method (interp.c:3885)
4 MarketPrimeTool.Net 0x0000000104b82de8 interp_runtime_invoke (interp.c:2122)
5 MarketPrimeTool.Net 0x0000000104b4aedc mono_jit_runtime_invoke (mini-runtime.c:3650)
6 MarketPrimeTool.Net 0x0000000104a8b874 mono_runtime_try_invoke (object.c:2415)
7 MarketPrimeTool.Net 0x0000000104a8d8a0 mono_runtime_invoke (object.c:2464)
8 MarketPrimeTool.Net 0x0000000104c42b68 native_to_managed_trampoline_68(objc_object*, objc_selector*, _MonoMethod**, objc_object*, unsigned int) (registrar.mm:4511)
9 MarketPrimeTool.Net 0x0000000104c42a00 +[__NSObject_Disposer drain:] (registrar.mm:20968)
10 Foundation 0x00000001adc13b14 __NSThreadPerformPerform + 260
This happens because we try to access freed/invalid memory, but unfortunately
the crash report / stack trace does not contain any hint whatsoever about the
memory that triggered the crash.
By adding an opt-in to validate the memory for a given object, we might be
able to detect this crash in a few cases, and instead throw a managed
exception with much more information.
Ref: dotnet#19493
rolfbjarne
added a commit
to rolfbjarne/xamarin-macios
that referenced
this issue
Jun 7, 2024
…d pointers.
This will hopefully make it easier to diagnose these kinds of crashes:
Thread 0 Crashed:
0 libobjc.A.dylib 0x00000001a6f6e7f8 object_getClass + 48
1 MyTestDotNetApp.Net 0x0000000104b90a68 do_icall (interp.c:2273)
2 MyTestDotNetApp.Net 0x0000000104b8f838 do_icall_wrapper (interp.c:2361)
3 MyTestDotNetApp.Net 0x0000000104b85214 interp_exec_method (interp.c:3885)
4 MyTestDotNetApp.Net 0x0000000104b82de8 interp_runtime_invoke (interp.c:2122)
5 MyTestDotNetApp.Net 0x0000000104b4aedc mono_jit_runtime_invoke (mini-runtime.c:3650)
6 MyTestDotNetApp.Net 0x0000000104a8b874 mono_runtime_try_invoke (object.c:2415)
7 MyTestDotNetApp.Net 0x0000000104a8d8a0 mono_runtime_invoke (object.c:2464)
8 MyTestDotNetApp.Net 0x0000000104c42b68 native_to_managed_trampoline_68(objc_object*, objc_selector*, _MonoMethod**, objc_object*, unsigned int) (registrar.mm:4511)
9 MyTestDotNetApp.Net 0x0000000104c42a00 +[__NSObject_Disposer drain:] (registrar.mm:20968)
10 Foundation 0x00000001adc13b14 __NSThreadPerformPerform + 260
This happens because we try to access freed/invalid memory, but unfortunately
the crash report / stack trace does not contain any hint whatsoever about the
memory that triggered the crash.
By adding an opt-in to validate the memory for a given object, we might be
able to detect this crash in a few cases, and instead throw a managed
exception with much more information.
A project opts-in by setting `_ValidateObjectPointers=true` in the csproj.
Ref: dotnet#19493
rolfbjarne
added a commit
that referenced
this issue
Aug 12, 2024
…d pointers. (#21001) This will hopefully make it easier to diagnose these kinds of crashes: Thread 0 Crashed: 0 libobjc.A.dylib 0x00000001a6f6e7f8 object_getClass + 48 1 MyTestDotNetApp.Net 0x0000000104b90a68 do_icall (interp.c:2273) 2 MyTestDotNetApp.Net 0x0000000104b8f838 do_icall_wrapper (interp.c:2361) 3 MyTestDotNetApp.Net 0x0000000104b85214 interp_exec_method (interp.c:3885) 4 MyTestDotNetApp.Net 0x0000000104b82de8 interp_runtime_invoke (interp.c:2122) 5 MyTestDotNetApp.Net 0x0000000104b4aedc mono_jit_runtime_invoke (mini-runtime.c:3650) 6 MyTestDotNetApp.Net 0x0000000104a8b874 mono_runtime_try_invoke (object.c:2415) 7 MyTestDotNetApp.Net 0x0000000104a8d8a0 mono_runtime_invoke (object.c:2464) 8 MyTestDotNetApp.Net 0x0000000104c42b68 native_to_managed_trampoline_68(objc_object*, objc_selector*, _MonoMethod**, objc_object*, unsigned int) (registrar.mm:4511) 9 MyTestDotNetApp.Net 0x0000000104c42a00 +[__NSObject_Disposer drain:] (registrar.mm:20968) 10 Foundation 0x00000001adc13b14 __NSThreadPerformPerform + 260 This happens because we try to access freed/invalid memory, but unfortunately the crash report / stack trace does not contain any hint whatsoever about the memory that triggered the crash. By adding an opt-in to validate the memory for a given object, we might be able to detect this crash in a few cases, and instead throw a managed exception with much more information. A project opts-in by setting `_ValidateObjectPointers=true` in the csproj. Ref: #19493 --------- Co-authored-by: Manuel de la Pena <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Help!
Can anyone help me understand how I could detect issue in my code, as those addresses are outside of code. I suspect that all point is
but unable to nail the cause in C# code. If anyone has slightest idea, would be very very appreciated for any advice.
Please,
Steps to Reproduce
Expected Behavior
Not seeing the crash, or at least understand what code of MarketPrimeTool.Net made it to happen
Actual Behavior
Seeing the crash
Environment
Production
Crash Log
The text was updated successfully, but these errors were encountered: