Runtime: Exceção através de PInvoke

Criado em 26 jul. 2017  ·  3Comentários  ·  Fonte: dotnet/runtime

Estou testando o seguinte código.

using System;
using System.Runtime.InteropServices;

class Program
{
    [DllImport("libupcall.so")]
    public static extern void register_callback(Callback cb);

    [DllImport("libupcall.so")]
    public static extern void upcall();

    public static void MyStaticCallback(int val)
    {
        throw new Exception("error");
    }

    public delegate void Callback(int var);
    static Callback cbMyStaticCallback = MyStaticCallback;  

    static void Main(string[] args)
    {
        try {
            register_callback(MyStaticCallback); 
            upcall();                

        } catch (Exception e) {
            Console.WriteLine("Catch clause caught : {0} \n", e.Message);
        }
    }
}

libupcall.so é baseado no seguinte código-fonte C

#include <stdio.h>

typedef void (*callback)(int val);

callback gCB;

extern void register_callback(callback cb)
{
    printf("register_callback:%p ----\n", (void *)cb);
    gCB = cb;
}
extern void upcall()
{
    static int c = 0;
    printf("upcall ----\n");
    gCB(c++);
}

dotnet run sai com exceção não tratada da seguinte forma.

twoflower@js2-desktop:~/dev/complexexception$ sudo dotnet run
register_callback:0x7f3a041f407c ----
upcall ----

Unhandled Exception: System.Exception: error
   at Program.MyStaticCallback(Int32 val) in /home/twoflower/dev/complexexception/Program.cs:line 14
   at Program.upcall()
   at Program.Main(String[] args) in /home/twoflower/dev/complexexception/Program.cs:line 24
twoflower@js2-desktop:~/dev/complexexception$ 

aqui está o corefile bt.

* thread dotnet/coreclr#1: tid = 0, 0x00007fda93b26428 libc.so.6`__GI_raise(sig=6) + 56 at raise.c:54, name = 'dotnet', stop reason = signal SIGABRT
  * frame #0: 0x00007fda93b26428 libc.so.6`__GI_raise(sig=6) + 56 at raise.c:54
    frame dotnet/coreclr#1: 0x00007fda93b2802a libc.so.6`__GI_abort + 362 at abort.c:89
    frame dotnet/coreclr#2: 0x00007fda9326258c libcoreclr.so`??? + 124
    frame dotnet/coreclr#3: 0x00007fda9326148b libcoreclr.so`??? + 235
    frame dotnet/coreclr#4: 0x00007fda92f0b893 libcoreclr.so`??? + 531
    frame dotnet/coreclr#5: 0x00007fda92f0cd71 libcoreclr.so`??? + 593
    frame dotnet/coreclr#6: 0x00007fda92fcaae3 libcoreclr.so`??? + 51
    frame dotnet/coreclr#7: 0x00007fda93ecb263 libgcc_s.so.1`_Unwind_RaiseException(exc=0x0000000002467530) + 115 at unwind.inc:113
    frame dotnet/coreclr#8: 0x00007fda9446790c libstdc++.so.6`__cxa_throw + 92
    frame dotnet/coreclr#9: 0x00007fda9322749d libcoreclr.so`??? + 77
    frame dotnet/coreclr#10: 0x00007fda92fd781e libcoreclr.so`??? + 273
    frame dotnet/coreclr#11: 0x00007fda88e4b7b2 libupcall.so`upcall + 45 at upcall.c:16
    frame dotnet/coreclr#12: 0x00007fda19d85ae6
    frame dotnet/coreclr#13: 0x00007fda19d8588e
    frame dotnet/coreclr#14: 0x00007fda92fd67b7 libcoreclr.so`??? + 124
    frame dotnet/coreclr#15: 0x00007fda92eec630 libcoreclr.so`??? + 1264

Esse comportamento normal é que o bloco de captura na função Main não captura a exceção?

Comentários muito úteis

Uma das razões é que realmente não sabemos como propagar a exceção por meio do código nativo que chamou o retorno de chamada gerenciado, pois não temos ideia de que tipo de código era. Poderia ter sido código C, código C++, código ASM ou de fato qualquer outro código de linguagem. Se apenas pulássemos esses quadros e fosse, por exemplo, C++, não estaríamos chamando destruidores de objetos de pilha, possivelmente vazando memória ou abandonando bloqueios bloqueados, etc. Se tentássemos lançar alguma exceção C++ predefinida por meio disso, o código nativo poderia engoli-lo sem querer. Ou pode até mesmo quebrar alguns runtimes que não estão prontos para processar exceções.

Todos 3 comentários

O cruzamento de exceção gerenciado para o limite nativo (como no seu caso quando um retorno de chamada é chamado do código nativo e lança uma exceção) não é intencionalmente suportado no dotnet core. Você precisará capturar todas as exceções em seus retornos de chamada que você chama do código nativo.

Uma das razões é que realmente não sabemos como propagar a exceção por meio do código nativo que chamou o retorno de chamada gerenciado, pois não temos ideia de que tipo de código era. Poderia ter sido código C, código C++, código ASM ou de fato qualquer outro código de linguagem. Se apenas pulássemos esses quadros e fosse, por exemplo, C++, não estaríamos chamando destruidores de objetos de pilha, possivelmente vazando memória ou abandonando bloqueios bloqueados, etc. Se tentássemos lançar alguma exceção C++ predefinida por meio disso, o código nativo poderia engoli-lo sem querer. Ou pode até mesmo quebrar alguns runtimes que não estão prontos para processar exceções.

Muito obrigado.

Esta página foi útil?
0 / 5 - 0 avaliações