G-WAN с valgrind? Альтернативы?

Question

G-WAN - это удобный способ запуска кода C в Интернете из коробки, но для меня это не работает с valgrind. (Запуск valgrind ./gwan появляется сообщение об ошибке Inconsistency detected by ld.so: rtld.c: 1292: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed!, а затем он выходит, система Debian Jessie 64bit).

Вопрос:
1) Должен ли G-WAN работать с valgrind?
2) Есть ли другие жизнеспособные варианты для обнаружения ошибок памяти в C-коде, запущенном под G-WAN?

Answer 1

Должен ли G-WAN работать с valgrind?

Мы проверили Valgrind, и, хотя он делает много прав, это просто не подходит для высококонкурентных заданий (даже с низким уровнем параллелизма является проблемой с Valgrind).

Возможные варианты обнаружения ошибок памяти в C-коде, запущенном под G-WAN?

Использование malloc() оберток, предварительно выделены пулы, или еще лучше, использовать alloca(), чтобы избежать проблем с памятью, в первую очередь.

Обратите внимание, что G-WAN обрабатывает плохие указатели в сценариях C без сбоев сервера, см: http://gwan.ch/developers#crash

Этот код ошибки:

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

... будет производить что-то вроде следующего 'изящный' отчет о сбое:

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 заходит так далеко, чтобы сказать вам, где ошибка произошло в исходном коде (смотрите примеры crash_xxx.c G-WAN) вместо убить серверный процесс.

Если вы не хотите отлаживать код C, используйте Java или Scala (оба поддерживаются G-WAN) - вам понадобится гораздо больше памяти, потому что ваши данные останутся загруженными до тех пор, пока GC не замедлит все, чтобы освободить то, что он думает, может быть освобожден - но по крайней мере вы будете получать меньше ошибок, связанных с памятью, если они есть.

---

По запросу человека, задающего вопрос, просьба обращаться по более подробной информации.

В конце 2012 года мы проверили десяток бесплатных и коммерческих инструментов, которые, как и Valgrind, должны помочь отлаживать параллелизм. Мы также использовали статические инструменты, изучающие исходный код, а не только динамические инструменты, работающие над запущенными (скомпилированными) программами.

Печальная истина состоит в том, что все они страдают от общих проблем, они:

• , как правило, слишком медленно, чтобы поддерживать параллелизм (основной выпуск)
• производят gazillions тривиальных предупреждений (и даже больше ложных предупреждений)
• очень дорогие (это, конечно, коммерческие) и не всегда могут быть протестированы перед покупкой (!)

Таким образом, после нескольких недель проверки и фильтраций всех этих результатов, мы потратили много времени на «исправление» в кодовой G-WAN, чтобы удалить тривиальные и ложные сигналы (предупреждения, вызванные инструментами, которые не могут отличить действительный код из багги-кода) ... но, к нашему сожалению, в то время мы не обнаружили никакой реальной ошибки в G-WAN (ясно, что эти недели были потрачены впустую).

Следовательно, вышеприведенный вывод: попробуйте сделать простой код, когда это возможно, и попытайтесь предварительно выделить блоки, когда необходимы более сложные стратегии.

Конечно, тот факт, что LIBC Linux настаивает на том, чтобы убивать приложения с (нераспространяемыми) сигналами abort, не помогает (это предотвращает восстановление программы или отбрасывание соответствующей трассы), особенно для неаккуратного двойного доступа Обнаружение LIBC Linux (которое ошибочно предполагает, что весь код использует свой malloc(), когда программа использовала malloc() один раз, что часто делается с помощью вызовов LIBC!). И я даже не говорю о ошибках mmap() или об отключении OOM.

Единственное решение, с которым мы работаем, заключается в том, чтобы избежать использования LIBC Linux и скомпилировать все, что нам нужно, с нашей собственной C-средой выполнения. Это немного сложно порекомендовать как «что делать» для всех пользователей, но это сработало для нас.

Мы будем рады видеть части нашего кода (или, по крайней мере, некоторые из концепций, реализованных в G-WAN), используемых Linux, поскольку это значительно упростит нашу жизнь (и один из многих других разработчиков) , но контакты, которые мы имели в прошлом с «ответственными людьми», не были обнадеживающими.

В целом, есть возможности для усовершенствований, от ОС, от независимых поставщиков ПО, как от нас, так и от разработчиков. В конце концов, параллелизм является «единственным» мейнстримом с 2004 года ... почти десять лет назад.