Forum Xamarin.Mac


The Xamarin Forums have officially moved to the new Microsoft Q&A experience. Microsoft Q&A is the home for technical questions and answers at across all products at Microsoft now including Xamarin!

To create new threads and ask questions head over to Microsoft Q&A for .NET and get involved today.

Crash on objc_release/objc_msgSend

Hello everyone!

We are using Xamarin in our Mac application and started to receive random crashes with the following crash stack:

Thread 25 Crashed:: Thread Pool Worker
0   libobjc.A.dylib                 0x00007fff7478bd5c objc_release + 28
1   libobjc.A.dylib                 0x00007fff7478cc8c (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 726
2        0x00007fff485feee6 _CFAutoreleasePoolPop + 22
3            0x00007fff4a9aba5e -[NSAutoreleasePool drain] + 144
4   com.os33                        0x000000010db021c3 xamarin_thread_finish(void*) + 147
5   com.os33                        0x000000010db01f6c thread_end(_MonoProfiler*, unsigned long) + 28
6   com.os33                        0x000000010dd1ff4d mono_profiler_raise_thread_stopped + 77
7   com.os33                        0x000000010dd5bd2b mono_thread_detach_internal + 1275
8   com.os33                        0x000000010dd62d35 start_wrapper_internal + 693
9   com.os33                        0x000000010dd62a57 start_wrapper + 71
10  libsystem_pthread.dylib         0x00007fff75a5a305 _pthread_body + 126
11  libsystem_pthread.dylib         0x00007fff75a5d26f _pthread_start + 70
12  libsystem_pthread.dylib         0x00007fff75a59415 thread_start + 13


Thread 23 Crashed:: Thread Pool Worker
0   libobjc.A.dylib                 0x00007fff59c5aa29 objc_msgSend + 41
1   libobjc.A.dylib                 0x00007fff59c62dd4 objc_object::sidetable_release(bool) + 268
2   libobjc.A.dylib                 0x00007fff59c5dc8c (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 726
3        0x00007fff2dac8ee6 _CFAutoreleasePoolPop + 22
4            0x00007fff2fe75a5e -[NSAutoreleasePool drain] + 144
5   com.os33                        0x00000001006851c3 xamarin_thread_finish(void*) + 147
6   com.os33                        0x0000000100684f6c thread_end(_MonoProfiler*, unsigned long) + 28
7   com.os33                        0x00000001008a2f4d mono_profiler_raise_thread_stopped + 77
8   com.os33                        0x00000001008ded2b mono_thread_detach_internal + 1275
9   com.os33                        0x00000001008e5d35 start_wrapper_internal + 693
10  com.os33                        0x00000001008e5a57 start_wrapper + 71
11  libsystem_pthread.dylib         0x00007fff5af2b305 _pthread_body + 126
12  libsystem_pthread.dylib         0x00007fff5af2e26f _pthread_start + 70
13  libsystem_pthread.dylib         0x00007fff5af2a415 thread_start + 13

I've tried to use the following trick but it doesn't help much =(

new System.Threading.Thread (() => 
  while (true) {
    System.Threading.Thread.Sleep (100);
    GC.Collect ();
}).Start (); 

I can't reproduce this issue but tried to run application with NSZombieEnabled=1 and I was able to get the following error after I caught my crash:

[__NSCFLocalDataTask release]: message sent to deallocated instance 0x7fa7f4da2190
Illegal instruction: 4

Does anybody know what is __NSCFLocalDataTask? I can't find much about this class, looks like it something from NSURLSessionTask but I'm not sure.

I don't think I can use Instruments's Zombie since I was never able to catch this crash while debugging from Visual Studio. Are there any other technics with NSZombieEnabled I can try out?


  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai
    edited February 2019

    Looks like you've done some good homework so far. That GC.Collect trick is the first one I pull out when you have random crashes.

    Often things that begin with __NSCF the like are internal concrete classes Apple uses to implement public types. A guess that it's NSURLSessionTask related seems reasonable. A few things you could consider doing:

    • You can enable AOT which sometimes provides better stack traces and performance (at a cost of larger app bundles).
    • Instruments is often difficult to use, as there is a random hang with mono during garbage collection and it can often change timing, as you found.
    • Have you tried isolating your NSURLSessionTask code in a sample app to reduce your test case? If you can get a smaller test case you could consider filing an issue.
    • Do you have any delegates assigned to networking APIs? I've seen cases (with WebView) where if you don't null out the delegate after killing the object you can randomly get callbacks after death (even in ObjC)
    • Have you tried multiple versions of Xamarin.Mac?
  • michaelkamichaelka Member ✭✭

    Hello again!

    ChrisHamons, thank you for answering!
    After enabling of AOT I'm still getting the same crash stack. Also I was able to catch this crash on different versions of Xamarin.Mac (I've seen it on 4.x and 5.2) so I think it doesn't related to Xamarin versions.

    Also I found HttpClient Default Handler option in Mac build settings. We used NSUrlSession and I changed it to Managed hoping that this should resolve the crash but after several days I got it again.

    I'm not using NSUrlSession directly in our code, only HttpClient. Is it still possible to get crashes related to NSURLSessionTask when Managed option selected? May be CFNetwork option can help?

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai

    According to our documentation NSUrlSession is the correct option for a vast majority of projects, so I would stick with that. I don't believe that should be the source of your problems.

    The fact that you are seeing it in 4.x and 5.x suggests that you are either hitting a problem in multiple versions of mono or there is a bug in your networking code.

    I would try to isolate your networking code in a small sample, either to make debugging easier or to be able to post it to an issue.

    Would you be able to post that, so we can see how you are using the API. In some cases crashes are caused by misuse, sometimes minutes after the API in question was invoked.

Sign In or Register to comment.