Понимаю, что немного не по теме форума, но столкнулся с интересным багом.

программа в Visual studio 2008, C++/MFC, использую zlib.dll.
под VS в режимах Release/Debug работает отлично, при самостоятельном запуске
работает 1 раз из 5. Т.е. 4 раза сваливается с обращением в 0 из ntdll.dll, 1 раз работает норм.
Гонял под IDA и с запуском из IDA, и через Attach to process - багов нет...
На наличие неинициализированных переменных проверял, все ОК.

Кто-нить может дать наметку, что за херь такая?

| Сообщение посчитали полезным:

PS. т.к. уже долго с этим багом гоняюсь и весь код перепроверил - начинаю грешить на zlib.

| Сообщение посчитали полезным:

Расставь маркеры, с выводом на экран или в файл. До места, где маркер не появился и будет баг. Постепенно сузишь круг. Вообще такой баг бывает при изменении кода, тогда надо FlushInstructionCache вызывать и в многопоточных прогах...

-----
IZ.RU

| Сообщение посчитали полезным:

маркеры стоят, все пишется в лог. прикол в том, что вылетает все время в разном месте.
может правда с потоками проблемы, надо копнуть. скорее всего zlib не thread-safe.
не могу только объяснить, почему при запуске из VS или под IDA все работает.

| Сообщение посчитали полезным:

Под отладчиком время на потоки делится почти поровну, если на одном проце.

-----
IZ.RU

| Сообщение посчитали полезным:

2 ядра

| Сообщение посчитали полезным:

DoctorCrash пишет:
Кто-нить может дать наметку, что за херь такая?
Сталкивался с таким при своих ошибках работы с памятью(не выделил и юзаешь пямять;выделил,но на 1 меньше чем нужно; выделил,но потом освободил раньше,чем нужно и т.д.)

| Сообщение посчитали полезным:

Потому что отладчики MSVC и IDA перехватывает исключения, пробуй __try/__except раставить

-----
Gutta cavat lapidem. Feci, quod potui. Faciant meliora potentes

| Сообщение посчитали полезным:

coolangel
+10

Ошибка наверняка при работе с памятью. Это наиболее часто встречающаяся ошибка при работе с Си/Си++ кодом. А вот какая именно, надо смотреть. Лично я чаще встречал выход за диапазон массива (в смысле не только у себя).

Советую выставить вот эти вещи (в режиме Debug, разумеется):

Smaller Type checks: Yes (/RTCc)
Basic runtime checks: Both (/RTC1, equiv. to /RTCsu)
Buffer Security Check: Yes

| Сообщение посчитали полезным:

Советы по программированию от DenCoder'а:

1) Чтоб было меньше ошибок, связанных с памятью, new/delete (malloc/free; HeapAlloc; HeapFree; ....) нужно сразу пиcать как скобки и между ними уже писать код. Подобные ошибки при таком подходе снижаются сразу на порядок, а то и на 2.

2) Если предполагается изменение кода в функции, то рекомендуется после new ставить {, перед delete ставить }. Это дает такие возможности как collapse/expand, и Ctrl + [ для быстрого перехода между фрагментами кода.

3) В многопоточных программах идеально если память выделяется и освобождается одним и тем же потоком. Но в любом случае нужно обеспечить хорошую синхронизацию, при этом никогда не полагаться на какой-то график выполнения потоков. Их очередность выполнения случайна.

4) Для отлова ошибок обращения к памяти рекомендую перед каждым обращением к функции, среди аргументов которой любые указатели, добавить if(IsBadReadPtr()) / / if(IsBadWritePtr()). Это позволит сузить круг подозрений.

5) Также в многопоточных программах не рекомендуется передавать в поток указатели на локальные переменные какой-либо функции других потоков, если поведение потока-владельца стека трудно предсказуемо.

-----
IZ.RU

| Сообщение посчитали полезным:

DoctorCrash может не совсем в тему. глядиш поможет. както из из ИДЫ в Делфи копировал куски кода. ИДА вместо PUSHAD отдизасемблила PUSHA, прога моя падала проработав разное количество времени (стэк начинал налазить на область данных). Сидел рученками контролил стэк. Метод половинного деления кода вам в помощь. Ну и удачи.
З.Ы. еще фигня. я собственно Делфист. Была хрень когда под Делфей прога раб. стэйб а сама крешица. Тоже было дело в том что делфя сама освобождает обьекты в процессе если ты забыл им сделать Фрии/Дестрой.

-----
Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме....

| Сообщение посчитали полезным:

VodoleY пишет:
ИДА вместо PUSHAD отдизасемблила PUSHA
Инструкция pusha в иде сразу учитывает разрядность и предполагает её 32-битной. Если у делфи кривой ассемблер, повод ругаться на дельфю, а не на иду.

| Сообщение посчитали полезным:

VodoleY пишет:
может не совсем в тему. глядиш поможет. както из из ИДЫ в Делфи копировал куски кода. ИДА вместо PUSHAD отдизасемблила PUSHA,
Ниразу не видел чтобы Delphi использовала PUSHAD при генерации кода. Скорее всего вы сами баловались с асмовыми вставками - отсюда и все ваши глюки.

| Сообщение посчитали полезным:

int тут собственно я не на что не ругаюсь, суть высказывания была в том, что присутствует человеческий фактор и 1 буква в опечатке может приводить к многим часам дебага.Даже машинисткам при наборе отводица 2процента на опечкатки. А глюки могут быть коварны
dermatolog а я не говорил что делфи ее испльзовало, я переносил в Делфи кусок кода из ИДЫ

-----
Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме....

| Сообщение посчитали полезным:

Всем спасибо. разобрался. проблем было несколько, основная - не thread-safe строки и переполнение heap.

| Сообщение посчитали полезным:

Закрою тогда, раз разобрался.

| Сообщение посчитали полезным: