使用valgrind的G-WAN？替代方案？

Question

G-WAN是一种开箱即用的在web上运行C代码的便捷方式，但对我来说，它不适用于valgrind。(运行valgrind ./gwan时会出现一条错误消息Inconsistency detected by ld.so: rtld.c: 1292: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed!，然后它就会退出；系统是Debian Jesse64bit)。

问题是：

1) G-WAN应该与valgrind一起工作吗？

2)在G-WAN下运行的C代码中，有没有其他可行的方法来检测内存错误？

Answer 1

应该与valgrind一起工作吗？

我们已经测试了Valgrind，虽然它做了很多正确的事情，但它就是不适合高并发作业(即使低并发也是Valgrind的问题)。

在G-WAN下运行的C代码中检测内存错误的可行选择？

使用malloc()包装器、预分配的池，甚至更好，使用alloca()从一开始就避免内存问题。

请注意，G-WAN处理C脚本中的错误指针时不会使服务器崩溃，请参阅：http://gwan.ch/developers#crash

这段错误代码如下：

int main(int argc, char *argv[])
{
   strcpy(0xBADC0DE, 0xBADC0DE);
   return 200;
}

...will会生成类似以下“优雅”的崩溃报告：

Script: crash_libc.c
 Client: 127.0.0.1
 Query : ?crash_libc

 Signal        : 11:Address not mapped to object
 Signal src    : 1:SEGV_MAPERR
 errno         : 0
 Thread        : 0
 Code   Pointer: 0000f5200b33 (module:/lib/libc.so.6, function:strcpy, line:0)
 Access Address: 00000badc0de

 Registers     : EAX=00000badc0de CS=00000033 EIP=0000f5200b33 EFLGS=000000010202
                 EBX=000000000001 SS=ec2d8ed4 ESP=0000f5ded828 EBP=0000f5dee020
                 ECX=000033323130 DS=ec2d8ed4 ESI=0000ec2d8f86 FS=00000033
                 EDX=000003b03c00 ES=ec2d8ed4 EDI=00000badc0de CS=00000033

 Module        :Function        :Line # PgrmCntr(EIP)  RetAddress  FramePtr(EBP)
      libc.so.6:          strcpy:     - 0000f5200b33 0000ec2d8f00   0000f5dee020
        servlet:            main:    37 0000ec2d8f00 00000042e10c   0000f5dee020        

而且，G-WAN甚至还会告诉您源代码中发生错误的位置(参见G-WAN crash_xxx.c示例)，而不是终止服务器进程。

如果你不想调试C代码，那么使用Java或Scala (两者都受G-WAN支持)-你将需要更多的内存，因为你的数据将保持加载状态，直到GC放慢速度--放慢一切以释放它认为可以释放的东西--但至少你会遇到更少的与内存相关的错误。

根据提出问题的人的要求，这里有更多详细信息。

在2012年末，我们已经测试了十几个免费的和商业的工具，比如Valgrind，它们应该有助于调试并发性。我们还使用了研究源代码的静态工具，而不仅仅是运行(编译)程序的动态工具。

可悲的事实是，他们都有共同的问题，他们：

• 通常太慢，无法支持并发性(核心issue)
• produce大量琐碎的警报(甚至更多错误警报)
• 非常昂贵(当然也可能是商业警报)，并且不能总是在购买(！)

之前进行测试

因此，经过几周的检查和过滤所有这些结果，我们花了很多时间“纠正”G-WAN代码库，以删除琐碎和错误的警报(由无法区分有效代码和错误代码的工具引起的警报)……但是，当时令我们沮丧的是，我们还没有在G-WAN中发现任何真正的bug (清楚地表明这几周是浪费时间)。

因此，上面的结论是:尽可能编写简单的代码，并在需要更复杂的策略时尝试预先分配块。

当然，Linux LIBC坚持用(不可捕获的)malloc信号杀死应用程序这一事实没有帮助(这会阻止程序恢复或转储相关的跟踪)，特别是对于草率的双自由Linux LIBC检测(它错误地假设当程序使用了abort ()一次时，所有代码都在使用它的malloc() --这通常是通过LIBC调用来完成的！)。我甚至不是在谈论mmap()失败，也不是在谈论OOM kill-switch。

到目前为止，我们找到的唯一有效的解决方案是避免使用Linux LIBC，并使用我们自己的C运行时编译所需的一切。对于所有用户来说，这是一件很难推荐的事情，但它对我们来说很有效。

我们很高兴看到我们的部分代码(或者至少是在G-WAN中实现的一些概念)被Linux使用，因为这将使我们的生活(以及许多其他开发人员)变得非常容易，但我们过去与“负责人”的联系并不令人鼓舞。

总而言之，有改进的空间，从操作系统，从像我们这样的is，从开发人员-毕竟，并发是自2004年以来的“唯一”主流……差不多十年前。