Page MenuHomePhabricator

C# binding DllImport problems with Mono 4
Open, NormalPublic


Some C# methods/constructors fail with mono 4 (Tested with 4.6.2 and 4.8.1) due to DllImport woes.

For example, instantiating a efl.Loop_Timer leads to a segfault, as internally the DllImport to efl_loop_timer_class_get ends up seemingly calling efl_ui_spin_class_get.

After bisect, the first commit with this kind of error is d1cce8256525bc8f9e76d7fd1afb30113a59b9ac, which just removes auto fit from ui_textpath. This together with the fact that everything works nice with mono v5, leads to the suggestion that the binding must be hitting some limitation related the mono v4 DllImport, causing something like a name collision.

lauromoura triaged this task as Normal priority.

Just a clarification: The aforementioned commit does not actually introduce this bug, only reveals it through the efl.Loop_Timer instantiation. This may happen to other native calls from the binding.

More info:

  • C# assembly code around the Loop_Timer constructor identical between mono v4 and mono v5
  • Removing another field (or fields) from efl_ui_text_path makes the constructor work.
  • Using MONO_LOG_LEVEL=debug MONO_LOG_MASK=dll shows the DllImport taking part before the method enters.

Looks like we found where the value changes:

  • Inside mono (4.8.1) loader.c, function mono_get_method_from_token', calls mono_metadata_impl_from_method`, which looks up the index on the C# assembly ImplMap table for the given Method index.
  • The method index is passed correctly, as checked with the output from monodis --method libefl_mono.dll, pointing to efl_loop_timer_class_get
  • But the ImplMap index returned refers to efl_ui_spin_class_get, as shown by monodis --implmap libefl_mono.dll

Still need to check why this change happens inside mono_metadata_impl_from_method.