最近遇到个比较经典的案例,在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的强引用就可以避免这个问题了