最近遇到个比较经典的案例，在c#中调用yara进行文件检测，yara是c编写的一个非常强大库，github有个大佬用c#对其进行了封装，使其能在跨平台下，只需编译yara的so或dll就能直接跑。但总是在Release版本下时不时就崩溃，而且崩的位置非常奇怪，在Debug版本下不会崩，分析了好久终于找到了原因

https://github.com/airbus-cert/dnYara

然后它提供了官方demo，看起来是没有问题的，但实际隐藏了个非常难排查的bug。

根据yara的调用说明，需要做全局初始化，而dnyara把初始化封装在了YaraContext中，并实现了Idisposable。可以看到在它的demo中，对ctx没有任何的引用，成为了一个悬置的变量。在下面Compile或者ScanFile的时候，就总是报内存访问异常。

起初还以为是yara c代码上的问题，但看了下它源码，发现这一段调用，没有明显的逻辑或者内存上的错误，那么就往.net上排查。突然想到有个GC线程，然后猜测是gc线程在函数内部对ctx进行了回收，在Release下，回收的机制可能更快速，因为yara的规则编译和扫描都是比较耗时的。顺便在chatgpt上进行了些求证

证明我的猜测基本是对的，GC的行为受编译器优化，而未引用变量会被编译器标记，导致gc在函数体内部进行回收。 这个地方显然是dnyara封装的锅，正确的封装方式为，不实现Idispose，写一个Release函数，让别个在外面手动调用。这样既保证了，释放处对ctx有引用不会被gc回收，又在没有引用的情况下，被回收也不会造成c库的内存错误。如果不改dnyara源码，随意增加一处对ctx的强引用就可以避免这个问题了