отлов багов в windows и linux

за что виндовая библиотека вызвала наряд и отправила тебя на исправительные работы. [[happy end]]

которые в линуксе себя не проявляли, а молча портили память, но на которые сразу же обратила внимание виндовая библиотека C

Эпично. Сейчас защитнички линукса обмакнут ТС в говно... как обычно. Только представьте, сколько софта в линуксе кособоко написано...

И некоторые еще удивляются почему линакс тормозит. Быдлокодеры же.

Другие же «решают» это покупкой более мощного железа, но это не всегда помогает.

А в обратную сторону это работает? А если с GCC и Clang одновременно?

переполнения, которые в линуксе себя не проявляли, а молча портили память, но на которые при первом же запуске обратила внимание виндовая библиотека C

Это как? Слова-то понятны, но вместе они не стыкуются.
Библиотека? Обратила внимание? Твоё? На твои ошибки?
Я тебя правильно понял?

Перефразируй свою мысль, а то страшно становится.

Запускаю в линуксе - все молча работает. Запускаю скомпилированую программу в виндовсе - выскакивает окошко Runtime VC library со словами, что в такой-то строчке я мимо массива пишу. Смотрю код - и в самом деле мимо.

А ты на плюсах пишешь или на чистом си?
Я что-то помню, что в какой-то из новых стандартов вносили проверку на попадание в массив... Или я путаю чего?

C++, под виндовсом использую visual studio express 2010

http://www.cplusplus.com/reference/array/array/operator[]
Это в STL добавили...
Или ты про std::array и говоришь?

скомпилируй свой код шлангом (clang -Wall) и проусти через valgrind.

нет ты молодец конечно, сишный код под плюсы перевёл, что ж ты хотел то.

нет, там обычный char name[10];, а я в него байт 15-20 записывал

Не понял твою мысль

я ошибся

Может быть в него только под вендой и попадают 15-20 байт? (намёк на utf-16)

Скомпиль в венде ядро.

Нет. там sprintf(tname, «thread%05i», i); 12 байт

valgrind'ом прогони свою софтину, что ли.

Советую Hardened Linux (PaX patches + grsecurity patches + selinux) - проявляется больше багов чем на OpenBSD и Windows вместе взятых. Так что приходиться вооружаться valgrind + gdb и исправлять, исправлять, исправлять.

Если код на Си - еще советую прогнать через Frama-C через Alt-Ergo solver. Он даже без аннотаций много логических ошибок показывает.

вот результат проверки серверной части

$ valgrind ./geodesic server
==19181== Memcheck, a memory error detector
==19181== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==19181== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==19181== Command: ./geodesic server
==19181== 
==19181== Mismatched free() / delete / delete []
==19181==    at 0x4C2AB5C: operator delete(void*) (vg_replace_malloc.c:480)
==19181==    by 0x4034ED: recv_server(void*) (in /home/vlad/data/distr/devel/geodesic/build/geodesic)
==19181==    by 0x402A25: main (in /home/vlad/data/distr/devel/geodesic/build/geodesic)
==19181==  Address 0x6fa0340 is 0 bytes inside a block of size 112 alloc'd
==19181==    at 0x4C2A067: operator new[](unsigned long) (vg_replace_malloc.c:363)
==19181==    by 0x4046D0: srv_get_start() (in /home/vlad/data/distr/devel/geodesic/build/geodesic)
==19181==    by 0x4034B4: recv_server(void*) (in /home/vlad/data/distr/devel/geodesic/build/geodesic)
==19181==    by 0x402A25: main (in /home/vlad/data/distr/devel/geodesic/build/geodesic)
==19181== 
recv FIN from 127.0.0.1
recv FIN from 127.0.0.1
recv FIN from 127.0.0.1
recv FIN from 127.0.0.1
recv FIN from 127.0.0.1
==19181== 
==19181== HEAP SUMMARY:
==19181==     in use at exit: 0 bytes in 0 blocks
==19181==   total heap usage: 10,033 allocs, 10,033 frees, 642,144 bytes allocated
==19181== 
==19181== All heap blocks were freed -- no leaks are possible
==19181== 
==19181== For counts of detected and suppressed errors, rerun with: -v
==19181== ERROR SUMMARY: 5 errors from 1 contexts (suppressed: 2 from 2)

Я так понял, что лишнее освобождение. Но совсем не понимаю, откуда там ему быть.

Тут всё ещё круче. Часть таких ошибок должен ловить компилятор:

$ cat ./test.c # Пример кода с ошибкой
int main(void)
{ int a[10];
  a[13] = 3;  
  return a[1];
}
$ gcc ./test.c -Wall # При компиляции даже с -Wall никаких ошибок
$ gcc ./test.c -Wall -O2 # А с -O2 появляются варнинги
./test.c: In function ‘main’:
./test.c:4:3: warning: ‘a[1]’ is used uninitialized in this function [-Wuninitialized]
   return a[1];
   ^
$ clang ./test.c -Wall # А вот clang ошибку ловит сразу
./test.c:3:3: warning: array index 13 is past the end of the array (which contains 10 elements) [-Warray-bounds]
  a[13] = 3;  // oops, overwrote the return address
  ^ ~~
./test.c:2:3: note: array 'a' declared here
{ int a[10];
  ^
1 warning generated.
$

Если же хочешь, чтобы ошибка ловилась именно рантаймом, то тут есть valgrind и ему подобные развлечения

$ gcc ./test.c -g -O0
$ valgrind ./a.out 
....
==26288== Syscall param exit_group(status) contains uninitialised byte(s)
==26288==    at 0x411106E: _Exit (_exit.S:33)
...
$ gcc -fstack-protector-all -fmudflap -lmudflap ./test.c
$ ./a.out 
*******
mudflap violation 1 (check/write): time=1384387918.033837 ptr=0xbfcac434 size=56
pc=0xb7658685 location=`./test.c:3:9 (main)'
      /usr/lib/i386-linux-gnu/libmudflap.so.0(__mf_check+0x45) [0xb7658685]
      ./a.out(main+0xa0) [0x804888d]
      /usr/lib/i386-linux-gnu/libmudflap.so.0(__wrap_main+0x4a) [0xb7658b3a]
Nearby object 1: checked region begins 0B into and ends 16B after
mudflap object 0x99f78c8: name=`./test.c:2:7 (main) a'
bounds=[0xbfcac434,0xbfcac45b] size=40 area=stack check=0r/3w liveness=3
alloc time=1384387918.033824 pc=0xb7658ad5
number of nearby objects: 1
$ 

Не пойму в чем проблема в линуксе пользоваться valgrind и gdb. Да и странно как-то ты пишешь, раз у тебя втихаря память рушится. Кроме того, не нужно отключать предупреждения (varnings) gcc. Наоборот лучше их на полную врубить.

Вообще, самый привередливый с/с++ компилятор - это от intel. И желательно там тоже уровень привередливости наивысший поставить. Хорошо так себя проверять.

Проверка на выход за границы массива включается автоматически для -O2 либо -Wall. Без включённой оптимизации многие проверки просто невозможны. Всё это описано в манах. Но кто же их читает?!

Пользуясь случаем, хочу спросить, кто-нибудь знает нормальные отладчики памяти типа валгринда под венду?

Стартовать valgrind с vgdb, подключиться gdb, при ошибке в валгринде в гдб случится точка останова, а там уже можно разбираться что вызвало, какие значения.

Содержимое $HOME/.valgrindrc:

--leak-check=full
--show-reachable=yes
--track-origins=yes
--read-var-info=yes
--suppressions=/home/user/valgrind/suppressions.supp

Так можно много чего отловить.

Эпично. Сейчас защитнички линукса обмакнут ТС в говно... как обычно. Только представьте, сколько софта в линуксе кособоко написано...

А ноет о том как его обижают.

gcc -Wall -Wextra -Weffc++, cppcheck, valgrind юзай

Т.е. всяких отладочных средств в программу куда больше засовывается.

Совершенно не обязательно. Есть все шансы, что просто жрёт больше ресурсов системы и тормозит :)

там sprintf

sprintf -> snprintf, gets -> fgets и т.д.

Не надо использовать небезопасные функции.

В линуксе в glibc тоже всякие проверки есть, дофига их. Только они по дефолту отключены, ибо предполагается что программист под линукс менее криворукий. man mcheck, man mallopt

там sprintf(tname, «thread%05i», i); 12 байт

Такое cppcheck хорошо отлавливает.

Ну а по исходной теме — ты сравнивал компиляторы, а написал так, будто сравниваешь ОС.

А что ты хочешь, рантайм проверки стоят дорого, оттого и просадка.

буду краток - gcc -Wall -pedantic

как с clang - не скажу, но явно там с этим будет еще и получше

А ноет о том как его обижают.

А это ты сам придумал или шаблонируешь?

Ты же тему создавал про хамство среди линуксоидов.

переходи на темную сторону! у нас есть питон и нам никуда не надо торопиться.

Вообще, самый привередливый с/с++ компилятор - это от intel.

Он в этом плане от гцц недалеко ушел. А самый жесткий - Comeau

-Werror, чтобы по хардкору!