Memory debugger

http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx

не?

MSDN subscription and sign in required

ничего не поделаешь, это майкрософт :)

попроси знакомых студентов КПИ, тут их есть

Самое трагичное то, что valgrind то молчит(когда тестю под Linux)... бида-бида и огорчение :)

Могу помочь открыть линк или что там. Но только завтра. Если надо - скастуй.

Мммм... gdb?

Если чесно то пока что не вижу путе его применения.

Недавно столкнулся с порчей памяти на винде.

Листал MSDN, начиная с этой статьи.

Ещё многие вин-девлы мне очень хвалили профайлер от Intel. Он правда платный, но есть триалка на 30 дней.

http://code.google.com/p/drmemory/

У меня бида в том что на WinXP32 все прекрасно работает... а вот на W7 x64 - проблема.

интелячий да, стащил... Но насколько я понял, эта сволотчь работает только с проектами студии... в крайнем случае я пока не нашел как скормить ему экзешник с дебаг символами...

угу :) Юзаю :) Медленно получается - жуть просто... Вчера не выдержал 30-ти минутного запуска :) Сегодня еще раз попробую...

Все нормальные тулы - платные. Я перепробовал: - Purify - Intel Inspector - BoundsChecker - Insure++

Остановился на последнем.

Что говорит анализ крэшдампа?

Креша не случается :)
Там glib/gkt приложение, которое ловит такие события :)
Вот думаю придется его переписывать малеха, что бы крешы случались :)

P.S. customized wireshark :)

Чтобы случился крэш, посмотри pageheap. DebugDiag тоже может оказаться полезным.

Если чесно то пока что не вижу путе его применения.

Ты не видишь путей применения gdb для отладки своей программы, которая некорректно работает с памятью?

мв, почитай тред прежде чем спорить.

мв, почитай тред прежде чем спорить.

Читал. Отловить дебаггером некорректную работу с памятью в программе, которая уже доходит до сегфолта - это не так сложно. Гораздо сложнее, если тихой сапой портятся данные.

Моя сложность в том что на 32-bit ной винде все пучком.... а на х64 все плохо...
При этом на фрях линуксах - все пучком... на обоих...
Ну и вторая сложность в том что вайршарк внутри хендлит такие ошибки, поэтому реальных сегфолтов не случается. И, соответственно, получить банальный бектрейс неоткуда.

Так же ужос ситуации в том что под Linux Мфдпкштв одобряет как i386 так и amd64 бинари... Т.о. я ищу мемори чекер именно для винды, который позволит получить информацию о том где же все таки засада.
Кода на самом деле не много, и он «чистый», glib-привязанный. Конечно я не исключаю того что там есть баги, но уже задолбался искать/проверять и вычитывать.

Мфдпкштв == Valgrind

Ты диссектор под ws, что ли, пишешь? У нас пачка их написана, работает под разными линуксами, вендой и макосью. Если выложишь код, то тебе, возможно, скажут, где ты неправ.

угу, написал :) И даже работает... Правда не под целевой платформой :)

ну раз кто-то хочет поглядеть в этот кромешный ад (шутка), то вечерком выложу.

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

http://ompldr.org/vY2gxbQ

А патча на wireshark сразу нет? И где pcap для воспроизведения ошибки можно взять?

ну pcap идет в комплекте с ваершарком или можна скачать с сайта

А это просто подложить в epan/dissectors и пропитьсать в сборочной системе(если VC, то в файл epan/Makefile.common - http://ompldr.org/vY2gzMQ)

ну pcap идет в комплекте с ваершарком или можна скачать с сайта

Ты диссектор для чего писал? У нас, например, свои диссекторы свои капчи требуют (со своими специфичными пакетами внутри).

А это просто подложить в epan/dissectors и пропитьсать в сборочной системе

Да это-то понятно, просто patch легче запустить ;) Ну да ладно.

pcap dump :)
http://ompldr.org/vY2hiNw

packet-pwg-common.c:215:1: error: conflicting types for 'pwg_dpcache_has_decoded_frame'
packet-pwg.h:67:1: note: previous declaration of 'pwg_dpcache_has_decoded_frame' was here
packet-pwg-common.c: In function 'pwg_dpcache_has_decoded_frame':
packet-pwg-common.c:218:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
packet-pwg-common.c:220:12: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
packet-pwg-common.c:221:33: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
packet-pwg-common.c: At top level:
packet-pwg-common.c:227:1: error: conflicting types for 'pwg_dpcache_get_frame'
packet-pwg.h:70:1: note: previous declaration of 'pwg_dpcache_get_frame' was here
packet-pwg-common.c: In function 'pwg_dpcache_get_frame':
packet-pwg-common.c:232:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
packet-pwg-common.c:236:11: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
packet-pwg-common.c:237:33: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

на gint32 смени, как в прототипе. Это я под виндой стандартные типы к битовым приводил :) Кстати ьсовский компилятор не ругался :)

В смысле такое приведение никак не повлияло на конечный результат :)

и в packet.-pwg.c строчки с 438 по 466 закоменть.

А код для венды ты точно тот же самый используешь?

И я бы в первую очередь выправил работу с памятью. А то что realloc возвращает, не проверяешь; на -1 из ...buff_init тоже болт кладёшь. Корень сишечных проблем лежит как раз в неаккуратной работе с памятью.

Это именно тот код который я и компилирую.
Про его грязность я в курсе. Проверки и т.д. действительно не реализованы «намеренно» :) . Поправить это не проблема и очень разумная идея, тут я согласен. Но это все равно не решит основной проблемы. Сегодня вычищу работу с памятью, там на пол часа работы :) Но всеравно где-то собака в другом месте порылась.

Спасибо за то что посмотрел.

У меня по ходу просмотра кода возникло два с половиной предположения:

0.5: realloc возвращает ошибку, никто на неё не смотрит.

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

2: некорректная работа с указателями: где-то закрался кастинг указателя в 32-битное целое, поэтому указатель со значащими старшими 32 битами портится. На 64-битном линуксе память выделяется ниже злосчастной границы, а на 64-битной венде выше. Или то же самое, но с 2 гигабайтами, если кастуется в int.

Но без возможности воспроизведения проблемы отловить косяк трудно, сам понимаешь ;)

Про реалок проверю, но это ооочень сомнительно. но проверю :)

Я тоже так думаю, но есть один неоспоримый факт - рабочие билды для x64 есть и они работают, и даже код собранный мной (32-битный) без моего модуля работает(правда я глубоко не тестил) на х64, откуда следует что это я кривой, а не винда+ваершарк.

Почти от всех sizeof и кастов избавился. в пользу статических размеров и битовых типов. Перепроверю конечно же :)... Еще раз :)

А в чем проблема воспроизведения ? не на чем ? :)

А в чем проблема воспроизведения ? не на чем ? :)

Ага.