mono - Mono（Linux）でのDLLImportのクラッシュ：icall_wrapper_mono_marshal_free

Question

LinuxでのMonoInteropの問題で立ち往生しています。C＃アセンブリで使用する必要のあるネイティブ共有ライブラリ（Lazarus製）があります。共有ライブラリは、WindowsおよびLinux上のMono C＃アセンブリによって使用されます。

アセンブリは、実行時にDllImportを介して共有ライブラリをロードし、ファイルを生成して新しいファイルの名前の文字列を返すエクスポートされた関数を呼び出します。共有ライブラリの関数は正常に機能しますが、Linuxでは、関数が戻ると、MonoランタイムがObject.__icall_wrapper_mono_marshal_freeでクラッシュします。これは、WindowsでMonoを使用すると正常に機能します。

いくつかのテストを行ったところ、共有ライブラリが実際に機能していることがわかりました（新しいファイルは指定されたパスで生成されます）が、最終的にランタイムがクラッシュします。intを返すエクスポートされた関数を使用すると機能するため、ランタイムには、結果の文字列をアセンブリに戻すマーシャリングに問題があるようです。

私の共有ライブラリは次のようなものです。

library fileProcessing;

{$mode objfpc}{$H+}
...

function ProcessFile(File, ResultPath: PChar): PChar; cdecl; // returns a null-terminated string, with a C ABI calling convention
var
  sFile, sPath, sResult: string;
begin
  sFile := StrPas(File);
  sPath := StrPas(ResultPath);
...
  sResult := GenerateNewFile(sFile, sPath); // helper function that generates the file and returns its filename
  Result := stralloc(length(sResult) + 1);
  Result := strpcopy(Result, sResult);
end;
...

exports ProcessFile name 'ProcessFile';

呼び出し元のC＃アセンブリは次のようになります。

namespace SIG
{
  public class TsigKernel
  {
...
    [DllImport("fileProcessing.so", CharSet=CharSet.Ansi,
         EntryPoint="ProcessFile",
         CallingConvention=CallingConvention.Cdecl, SetLastError = true)]
    private static extern string ex_ProcessFile(string File, string ResultPath);

    // managed wrapper for the shared library exported function
    public string ProcessFile(string File, string ResultPath)
    {
     return ex_ProcessFile(File, ResultPath);
    }
...
  }
}

私はいくつかの代替案を試しました（エクスポートされた関数からネイティブ文字列を返す、アセンブリと共有ライブラリで呼び出し規約をstdcallに変更する、DllImportの文字セットを変更する）。

私は何かが足りないと確信していますが、Googleでこの問題について何も見つかりませんでした。

私のクラッシュは次のようになります。

=================================================================  
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.  
=================================================================

Stacktrace:
  at (wrapper managed-to-native) object.__icall_wrapper_mono_marshal_free (intptr) <0x00004>
  at (wrapper managed-to-native) object.__icall_wrapper_mono_marshal_free (intptr) <0x00004>
  at (wrapper managed-to-native) SIG.TsigKernel.ex_ProcessFile (string, string) <0x00064>
  at SIG.TsigKernel.ProcessFile (string, string) <0x00010>
  at TEST.Form1.Form1_Load (object,System.EventArgs) <0x00047>
  at System.Windows.Forms.Form.OnLoad (System.EventArgs) <0x00060>
  at System.Windows.Forms.Form.OnLoadInternal (System.EventArgs) <0x00081>
  at System.Windows.Forms.Form.OnCreateControl () <0x00051>
  at System.Windows.Forms.Control.CreateControl () <0x0012e>
  at System.Windows.Forms.Control.WmShowWindow (System.Windows.Forms.Message&) <0x0010f>
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message&) <0x00292>
  at System.Windows.Forms.ScrollableControl.WndProc (System.Windows.Forms.Message&) <0x00013>
  at System.Windows.Forms.ContainerControl.WndProc (System.Windows.Forms.Message&) <0x00051>
  at System.Windows.Forms.Form.WndProc (System.Windows.Forms.Message&) <0x0022a>
  at System.Windows.Forms.Control/ControlWindowTarget.OnMessage (System.Windows.Forms.Message&) <0x0001d>
  at System.Windows.Forms.Control/ControlNativeWindow.WndProc (System.Windows.Forms.Message&) <0x0002d>
  at System.Windows.Forms.NativeWindow.WndProc (intptr,System.Windows.Forms.Msg,intptr,intptr) <0x001eb>
  at System.Windows.Forms.XplatUIX11.SendMessage (intptr,System.Windows.Forms.Msg,intptr,intptr) <0x002ae>
  at System.Windows.Forms.XplatUIX11.MapWindow (System.Windows.Forms.Hwnd,System.Windows.Forms.WindowType) <0x0019a>
  at System.Windows.Forms.XplatUIX11.CreateWindow (System.Windows.Forms.CreateParams) <0x00bb4>
  at System.Windows.Forms.XplatUI.CreateWindow (System.Windows.Forms.CreateParams) <0x0001d>
  at System.Windows.Forms.NativeWindow.CreateHandle (System.Windows.Forms.CreateParams) <0x00030>
  at System.Windows.Forms.Control.CreateHandle () <0x0007f>
  at System.Windows.Forms.Form.CreateHandle () <0x00014>
  at System.Windows.Forms.Control.CreateControl () <0x0008a>
  at System.Windows.Forms.Control.SetVisibleCore (bool) <0x00079>
  at System.Windows.Forms.Form.SetVisibleCore (bool) <0x0021d>
  at System.Windows.Forms.Control.set_Visible (bool) <0x0002c>
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control.set_Visible (bool) <0x00057>
  at System.Windows.Forms.Application.RunLoop (bool,System.Windows.Forms.ApplicationContext) <0x001f9>
  at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext) <0x00052>
  at System.Windows.Forms.Application.Run (System.Windows.Forms.Form) <0x00033>
  at TEST.Program.Main () <0x00044>
  at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0x0003a>

Native stacktrace:
mono [0x80d36a9]
[0xffffe410]
[0xffffe430]
/lib/libc.so.6(gsignal+0x4f) [0xb76430cf]
/lib/libc.so.6(abort+0x187) [0xb76449e7]
/lib/libc.so.6 [0xb767f4ed]
/lib/libc.so.6 [0xb768550b]
/lib/libc.so.6 [0xb7686de4]
/lib/libc.so.6(cfree+0x6d) [0xb7689fdd]
/usr/lib/libglib-2.0.so.0(g_free+0x36) [0xb780d886]
[0xb6561634]
[0xb5786a5d]
[0xb57869d1]
[0xb57866c8]
[0xb5786599]
[0xb578632a]
[0xb5785f7a]
[0xb605dbe7]
[0xb578c7c0]
[0xb578bbfb]
[0xb57820c4]
[0xb578208a]
[0xb5781eeb]
[0xb578b95e]
[0xb578b936]
[0xb578ac74]
[0xb5788acf]
[0xb578c4b3]
[0xb605eca5]
[0xb605e0e6]
[0xb605e069]
[0xb605ddf0]
[0xb57804bd]
[0xb605db43]
[0xb57938a2]
[0xb57800a6]
[0xb57937f5]
[0xb5793798]
[0xb577f062]
[0xb577ee13]
[0xb577eacc]
[0xb71ce1f5]
[0xb71ce26b]
mono [0x8063552]

何か案は？

score 2 · Accepted Answer

string一般に、ネイティブメソッド呼び出しからを返すことはお勧めできません。ケースの処理方法については、Monoのネイティブライブラリ（文字列）との相互運用ページを参照してください。返される文字列の最大サイズがわかっている場合は、StringBuilderアプローチが最適です。

score 2 · Accepted Answer

何が起こるかというと、C＃はLinuxのg_freeまたはWindowsのCoTaskMemFreeを使用して、返された文字列に割り当てられたメモリを解放しようとします。プログラムでg_allocまたはCoTaskMemAllocを使用してメモリを割り当てることができますが、C＃ではリターンタイプをIntPtrに変更し、Marshal.PtrToStringAutoを使用して文字列に変換することをお勧めします。また、アンマネージコードで他の関数に渡すことにより、返された文字列を解放する必要があります。

namespace SIG
{
  public class TsigKernel
  {
    ...
    [DllImport("fileProcessing.so", CharSet=CharSet.Ansi,
         EntryPoint="ProcessFile",
         CallingConvention=CallingConvention.Cdecl, SetLastError = true)]
    private static extern IntPtr ex_ProcessFile(string File, string ResultPath);

    [DllImport("fileProcessing.so", CharSet=CharSet.Ansi,
         EntryPoint="FreeText",
         CallingConvertion=CallingConvention.Cdecl, SetLastError = true)]
    private static extern void ex_FreeText(IntPtr str);

    // managed wrapper for the shared library exported function
    public string ProcessFile(string File, string ResultPath)
    {
      IntPtr str_ptr = ex_ProcessFile(File, ResultPath);
      string res = Marshal.PtrToStringAnsi(str_ptr);
      ex_FreeText(str_ptr);
      return res;
    }
    ...
  }
}

FreeTextのコード：

function FreeText(Str: PChar); cdecl; // frees previously allocated string, with a C ABI calling convention
begin
  strdispose(Str);
end;

score 0 · Accepted Answer

問題は、strallocが何を使用するかです。Monoでは、同等のコードは、返されたblobでg_freeを使用します。これは、libcfreeにマップされます。StrAllocが何か他のことをしている可能性があります。

mono - Mono（Linux）でのDLLImportのクラッシュ：icall_wrapper_mono_marshal_free

3 に答える 3

Related

Reference