Должен ли 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) — вам потребуется гораздо больше памяти, потому что ваши данные останутся загруженными до тех пор, пока сборщик мусора не замедлит все, чтобы освободить то, что, по его мнению, может быть освобождены - но, по крайней мере, вы получите меньше ошибок, связанных с памятью, если таковые имеются.
По просьбе человека, задавшего вопрос, вот более подробная информация.
В конце 2012 года мы протестировали дюжину бесплатных и коммерческих инструментов, которые, как и Valgrind, должны помочь в отладке параллелизма. Мы также использовали статические инструменты для изучения исходного кода, а не только динамические инструменты для работы с запущенными (скомпилированными) программами.
Печальная правда в том, что все они страдают от общих проблем, они:
- обычно слишком медленны для поддержки параллелизма (основная проблема)
- генерировать миллионы тривиальных предупреждений (и даже больше ложных предупреждений)
- очень дорогие (это или коммерческие, конечно) и не всегда могут быть протестированы перед покупкой (!)
Итак, после нескольких недель проверки и фильтрации всех этих результатов мы потратили много времени на «исправление» кодовой базы G-WAN, чтобы удалить тривиальные и ложные предупреждения (предупреждения, вызванные инструментами, которые не могут отличить правильный код от кода с ошибками). .. но, к нашему разочарованию в то время, мы не нашли никакой реальной ошибки в G-WAN (показывая, что эти недели были потрачены впустую).
Отсюда вывод выше: старайтесь делать простой код, когда это возможно, и старайтесь предварительно выделять блоки, когда нужны более сложные стратегии.
Конечно, тот факт, что Linux LIBC настаивает на уничтожении приложений с (неперехватываемыми) сигналами abort, не помогает (это не позволяет программе восстановить или сбросить соответствующую трассировку), особенно для неаккуратного обнаружения Linux LIBC с двойным освобождением ( который ошибочно предполагает, что весь код использует функцию malloc(), когда программа использовала функцию malloc() один раз — что часто делается с помощью вызовов LIBC!). И я даже не говорю ни о сбоях mmap(), ни о выключателе OOM.
Единственное решение, которое мы пока нашли работающим, — это отказаться от использования Linux LIBC и компилировать все, что нам нужно, с помощью нашей собственной среды выполнения C. Это немного сложно рекомендовать как "то, что нужно сделать" для всех пользователей, но это сработало для нас.
Мы были бы очень рады, если бы части нашего кода (или хотя бы некоторые концепции, реализованные в G-WAN) использовались Linux, так как это значительно облегчило бы нашу жизнь (и жизнь многих других разработчиков), но контакты то, что мы имели в прошлом с «ответственными людьми», не было обнадеживающим.
В общем, есть возможности для улучшений со стороны ОС, таких независимых разработчиков программного обеспечения, как мы, и со стороны разработчиков — в конце концов, параллелизм является «только» основным с 2004 года... почти десять лет назад.
person
Gil
schedule
16.07.2013
