C++ Heap corruption
У кого-нибудь есть идеи?видишь ошибку - локализуешь, изучаешь, находишь минимальный код, в котором она появляется, анализируешь, исправляешь, проверяешь, отображаешь на всё приложение, проверяешь, дальше по циклу.
А сама библиотека точно не содержит ошибок? Может в такой среде выявляются ошибки при работе с памятью? А если взять "небольшое" приложение и поработать в другом потоке?
Приложение многопоточноепосчитай, сколько раз вызывается этот самый деструктор, например.
локализуешь, изучаешь, находишь минимальный код,С локализацией все ясно, выделение коррапченого блока происходит в конструкторе класса, коррапт - в деструкторе.
Минимальный код найти нелегко, приложение использует еще десяток библиотек, если одну из них отключить - ничего не заработает. Само приложение тоже хер сократишь так, чтобы оно компилировалось.
А сама библиотека точно не содержит ошибок? Может в такой среде выявляются ошибки при работе с памятью? А если взять "небольшое" приложение и поработать в другом потоке?Может и содержит, например, в другом классе при передаче некоторых параметров конструктору происходит аналогичная ошибка, т.к. создается массив из 0 элементов, заполняется первый элемент и потом для массива вызывается delete.
Но такая ошибка произошла бы в любом случае. А тут конструктор + сразу же деструктор работают в маленьком приложении и не работают в большом.
посчитай, сколько раз вызывается этот самый деструктор, например.Идея хорошая, но к сожалению только один раз.
У кого-нибудь есть идеи?А какие тут могут быть идеи?
Многопоточный класс, создаёт поток для себя, записывает что-то в свои переменные после вызова деструктора или до завершения конструирования. В большом приложении поток не успевает запуститься, в маленьком - успевает. Можно ещё поставить какие-нибудь программы для диагностики.Тут без кода мы только с бубном для тебя поплясать можем, но эта услуга платная.
Многопоточный класс, создаёт поток для себя, записывает что-то в свои переменные после вызова деструктора или до завершения конструирования.А как это можно проверить?
А как это можно проверить?Посмотреть код?
А как это можно проверить?отладчиком, построением простенькой трассы
Многопоточный класс, создаёт поток для себя ...А такая ошибка будет устойчивой или периодической? Моя устойчива
А такая ошибка будет устойчивой или периодической? Моя устойчиваможет быть как угодно. например, запустил в фоне фильм - заработало, вырубил - слетело.
может кто-то где-то пишет слишком много или не по нужному адресу?
heap corruption возникает как на debug, так и на release-билде?
heap corruption возникает как на debug, так и на release-билде?
heap corruption возникает как на debug, так и на release-билде?На последнем проверка явно отключена.
может быть как угодно. например, запустил в фоне фильм - заработало, вырубил - слетело.Тогда не в этом дело, ошибка стабильная.
может кто-то где-то пишет слишком много или не по нужному адресу?
Логично, но почему этого не происходит при использовании либы в простом однопоточном приложении?
heap corruption возникает как на debug, так и на release-билде?
Да, при включенной в релизе проверке.
Логично, но почему этого не происходит при использовании либы в простом однопоточном приложении?Потому что так бывает в Си++.
Давай код, может быть, кто-нибудь тебе поможет. Мы люди занятые, чего нам тыкать пальцем в небо? 
Тут http://www.amanjit-gill.de/articles/vc6_debug.html написано, что такая ошибка может возникать при смешении рантаймов. Но у меня рантаймы для всех либ одинаковые, с разными они просто не линкуются.
Давай код,Я же сказал, что минимальный код не могу получить. Так что меня интересуют общие причины, вызывающие heap corruption. Пока что есть:
1) Вызов delete для того, для чего не было new и наоборот.
2) Запись потоком в удаленный класс.
3) Смешение рантаймов.
4) отсутствие синхронизации
a) использование однопоточных либ (в том числе, стандартных) из многопоточного приложения
5) промах по памяти (причем может быть и вообще в какой-нибудь левом коде, а в данном случае проявляется, потому что усилилась работа с памятью)
a) использование однопоточных либ (в том числе, стандартных) из многопоточного приложения
5) промах по памяти (причем может быть и вообще в какой-нибудь левом коде, а в данном случае проявляется, потому что усилилась работа с памятью)
Так что меня интересуют общие причины, вызывающие heap corruption.Общие причины, вызывающие heap corruption: запись в блок памяти после его освобождения (чаще всего выход за пределы выделенного блока памяти. Когда дебаггер вызывает assert он должен тебе написать, что именно случилось. Типа "HEAP: Free Heap block blahblah modified at blahblah after it was freed." И ещё можно напихать везде _heapchk и функций из той же группы, чтобы проверять, в какой момент времени что-то повреждается.
У меня запись после конца хип-буфера
У меня запись после конца хип-буфераЧто именно? Heap block at blahblah modified at blahblah past requested size of blahblah? Вставляй проверки, напиши CRT хуки для выделения памяти, внимательно изучай код. Кстати, ты за всё время не написал, либа-то статическая или dll какая?
HEAP CORRUPTION DETECTED: after Normal block (#273880) at 0x024E2F20 . CRT detected that the application wrote to memory after end of heap buffer.
Либа статическая, компилируется из исходников прямо в солюшене вместе с остальными либами и самим приложением.
Либа статическая, компилируется из исходников прямо в солюшене вместе с остальными либами и самим приложением.
компилируется из исходниковдык что мешает поглядеть в отладчике, где именно вылетает ошибка?.. какие при этом потоки работают, кто куда что пишет, итп.
Ну нехорошие действия могли быть сделаны раньше, причем потоком, которого уже нет.
А когда именно возникает ошика тоже не понятно. Ругается после delete A, где A - проблемный класс. Дебаггер в сам delete не заходит, сразу ругается, но если поставить брейк на деструктор, то сначала выполняется деструктор, а потом ошибка.
А когда именно возникает ошика тоже не понятно. Ругается после delete A, где A - проблемный класс. Дебаггер в сам delete не заходит, сразу ругается, но если поставить брейк на деструктор, то сначала выполняется деструктор, а потом ошибка.
HEAP CORRUPTION DETECTED: after Normal block (#273880) at 0x024E2F20 . CRT detected that the application wrote to memory after end of heap buffer.Ищи выход за пределы массива.
Либа статическая, компилируется из исходников прямо в солюшене вместе с остальными либами и самим приложением.
Дебаггер в сам delete не заходит, сразу ругается, но если поставить брейк на деструктор, то сначала выполняется деструктор, а потом ошибка.это скорее всего, во время freemem ругается какой-нибудь heapcheck который видит, что память кто-то попортил до этого.
Ругается после delete A, где A - проблемный класс.Ну естественно, ведь проверка хипа идёт после освобождения памяти. Вставь проверки хипа внутрь деструктора.
Поставил _heapchk непосредственно перед delete и в последней строчке деструкторов класса и его предков. Везде дает -2 (все ок после delete и пропуска ошибки тоже дает -2
Поставил _heapchk непосредственно перед delete и в последней строчке деструкторов класса и его предков. Везде дает -2 (все ок после delete и пропуска ошибки тоже дает -2Ты проверяешь неправильный хип (ничего себе заявление?). Попробуй _CrtCheckMemory, и вообще почитай уже что-нибудь про debugging, если уж у вас там такие криворукие программисты (на Си с классами).
Оставить комментарий
Devid
Такая ошибка возникает при использовании сторонней библиотеки, конкретно при вызове деструктора одного ее класса.Самое интересное, что ошибка есть только при использовании библиотеки в составе большого приложения. Если написать что-нибудь простое, что только создает и удаляет класс проблем нет.
Приложение многопоточное, класс тоже создает поток для себя, для компиляции используются одинаковые рантаймы. У кого-нибудь есть идеи?