Bug 31023 - [Profiler] * Assertion at proflog.c:682, condition `ji' not met
Summary: [Profiler] * Assertion at proflog.c:682, condition `ji' not met
Alias: None
Product: Runtime
Classification: Mono
Component: General ()
Version: unspecified
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Alex Rønne Petersen
: 31609 32647 33371 35062 ()
Depends on:
Reported: 2015-06-11 11:03 UTC by Stephen Shaw
Modified: 2016-02-29 18:07 UTC (History)
13 users (show)

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

Profiler log from console (11.04 KB, text/plain)
2015-09-10 08:54 UTC, Nick Turner

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 GitHub or Developer Community 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:

Description Stephen Shaw 2015-06-11 11:03:28 UTC
Here is the raw bits showing my env var and also command I ran to reproduce this (seems to be 100%). You'll need the profiler code to test this.

sshaw@MacLappy:~$ export MONO_ENV_OPTIONS="--gc=sgen --profile=log:heapshot=ondemand,alloc,nocalls,maxframes=8,sample=cycles/1000,output=-/Users/sshaw/tmp/My\ Mlpd\ Location/oisljrd4.mlpd"

sshaw@MacLappy:~$ mono ~/code/profiler/packages/xunit.runner.console.2.0.0/tools/xunit.console.exe ~/code/profiler/bin/Debug/XamarinProfiler.Tests.dll

Here is the output:

* Assertion at proflog.c:682, condition `ji' not met


  at <unknown> <0xffffffff>
  at System.Collections.Concurrent.ConcurrentDictionary<!0,!1>..cctor () <0x00027>
  at (wrapper runtime-invoke) System.Object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff>
  at <unknown> <0xffffffff>
  at Xunit.ConsoleClient.Program..cctor () <0x0001f>
  at (wrapper runtime-invoke) System.Object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

	0   mono                                0x00117ed6 mono_handle_native_sigsegv + 342
	1   mono                                0x00168681 sigabrt_signal_handler + 129
	2   libsystem_platform.dylib            0x930ad03b _sigtramp + 43
	3   ???                                 0xffffffff 0x0 + 4294967295
	4   libsystem_c.dylib                   0x97d61eee abort + 156
	5   libmono-profiler-log.0.dylib        0x004d7cc1 monoeg_log_default_handler + 129
	6   libmono-profiler-log.0.dylib        0x004d7dbb monoeg_assertion_message + 107
	7   libmono-profiler-log.0.dylib        0x004d20ac register_method_local + 188
	8   libmono-profiler-log.0.dylib        0x004d22d3 emit_bt + 195
	9   libmono-profiler-log.0.dylib        0x004caddb gc_alloc + 1083
	10  mono                                0x001f6ef1 mono_profiler_allocation + 65
	11  mono                                0x0026771c mono_gc_alloc_pinned_obj + 60
	12  mono                                0x0023755e mono_object_new_pinned + 62
	13  mono                                0x0024778b mono_type_get_object + 475
	14  mono                                0x00063f05 mono_resolve_patch_target + 869
	15  mono                                0x0010407b load_method + 1675
	16  mono                                0x001033b0 mono_aot_get_method + 864
	17  mono                                0x00065060 mono_jit_compile_method_with_opt + 656
	18  mono                                0x00064d79 mono_jit_compile_method + 57
	19  mono                                0x00119601 common_call_trampoline + 961
	20  mono                                0x0011922c mono_magic_trampoline + 60
	21  ???                                 0x00514088 0x0 + 5324936

Debug info from gdb:

Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.

Abort trap: 6
Comment 1 Stephen Shaw 2015-06-11 11:04:36 UTC
Comment 2 Alex Rønne Petersen 2015-06-11 18:35:47 UTC
Here is a reduced repro:

> using System.Collections.Concurrent;
> class Program {
>         static ConcurrentDictionary<string, Program> _dict = new ConcurrentDictionary<string, Program> ();
>         static void Main () {
>                 _dict.ToString ();
>         }
> }

Run with same command line args as in the original report.

What appears to go wrong is that `mono_method_is_generic_sharable_full (method, FALSE, FALSE, FALSE)` returns false for the `ConcurrentDictionary` cctor, making `mono_aot_get_method (domain, method)` fail to find it. Interestingly, looking it up with `mono_aot_get_method_from_token ()` works fine.
Comment 3 Zoltan Varga 2015-06-12 23:52:18 UTC
Fixed part of the problem in b50fdc594fe53c3573f95b43426bdac53012107b, but the other part still remains. The problem is that mono_sample_hit () calls mono_stack_walk_async_safe (), which doesn't inflate generic methods, so for generic shared methods, the async_walk_stack ( ) callback receives the shared method, which in this case, is ConcurrentDictionary<T_REF, T_REF):.cctor (). This method is an implementation detail in the runtime, it shouldn't really leak to the profiler, and thats why it is not found by 
mono_aot_get_method () etc.

Btw, the code in find_method () can be simplified to do
ip = mono_compile_method (method) + mono_jit_info_table_find ().
Comment 4 Zoltan Varga 2015-06-13 00:01:27 UTC
A possible fix is that in mono_stack_walk_full (), if MONO_UNWIND_LOOKUP_ACTUAL_METHOD is not set, we still call get_generic_info_from_stack_frame (frame.ji, &ctx), and save the result into StackFrameInfo.
That info gets passed to the mono_stack_walk () callback, i.e. walk_stack () in proflog.c, which saves it into FrameData, and later, when FrameData is processed outside of an async context, it can call some new embedding api function, passing in the method, and the data returned by get_generic_info_from_stack_frame () to obtain the actual method.
Comment 5 Udham Singh 2015-08-14 08:59:12 UTC
*** Bug 32647 has been marked as a duplicate of this bug. ***
Comment 7 Zoltan Varga 2015-08-21 15:08:52 UTC
Can we disable the assertion until this is truly fixed ?
Comment 8 Rodrigo Moya 2015-09-10 04:26:05 UTC
*** Bug 33371 has been marked as a duplicate of this bug. ***
Comment 9 Nick Turner 2015-09-10 08:52:46 UTC
I'm adding my reports for additional info. This occurs 100%.
Comment 10 Nick Turner 2015-09-10 08:54:20 UTC
Created attachment 12853 [details]
Profiler log from console

This shows the endless loop, thus causing an out of memory condition. This is because before the failed to connect fires there is a null exception.
Comment 12 Alex Rønne Petersen 2015-09-24 04:57:56 UTC
A fix for this is in mono-4.2.0-branch (2d9372887c50e0aed5413000f6c91181a2b48c17) and should be coming in the next alpha channel build.
Comment 13 Rodrigo Moya 2015-10-20 06:53:15 UTC
*** Bug 35062 has been marked as a duplicate of this bug. ***
Comment 14 Alex Rønne Petersen 2015-10-28 05:34:20 UTC
This should be fixed on both Mono master and 4.2. All products that use 4.2 should have gotten the fix.
Comment 15 Alex Rønne Petersen 2015-10-28 05:44:45 UTC
*** Bug 31609 has been marked as a duplicate of this bug. ***
Comment 16 Pavel Alekseev 2016-02-29 12:42:55 UTC
Hey guys! 

I'm using 
Xamarin Studio
Version 5.10.2 (build 56)
	Mono 4.2.2 (explicit/996df3c)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 402020030

Version: 0.31.0
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

And I still have an issue when trying to profile even a blank app!
Comment 17 Alex Rønne Petersen 2016-02-29 18:07:44 UTC
@Pavel: What sort of issue? The same issue as this bug? We need more details.