Ситуация такова.
Моя dll получает объект от основной программы, какое-то время работает с ним. Затем объект уничтожается основной программой.
Но в dll-ке есть баг, и dll-ка читает одно поле этого убитого объекта. av не происходит, но поведение программы изменяется - через какое-то время она выводит одиночное окошко с информативным сообщением. Смысл сообщения специфичен для предметной области и не относится к работе с памятью. И все.
Мне принципиально неясно как _чтение_ пусть даже разрушенных данных может быть зарегистрировано программой.

Программой - никак (если самому не делать костылей вокруг new/delete), а вот операционкой - вполне, ибо память не только "разрушается", но и освобождается.

dizzy1984, с таким подходом, тебе технологию COM надо юзать, либо писать что-то аналогичное.






Это сообщение отредактировал(а) 586 - 18.12.2009, 16:01

586, все правильно, это com-объект, но ты на вопрос-то ответь.
Как может быть реакция на чтение данных в адресном пространстве.

Предлагаю не проверять память, а просто по другому работать с объектом.
Как-нибудь так:

.exe

.dll

а что, собственно, удивляет?

пока память действительно не будет освобождена  кучей, все данные,
пусть даже и "мусорные", продолжают выполнять свою роль:
если это VMT, то она по прежнему указывает на методы, и методы по прежнему можно вызывать,

другое дело, что гарантии на целостность таких данных дает куча,
а после нормального удаления блока (delete, free и т.п.), этих гарантий больше нет,
и реакция любого метода под их воздействием может быть уже какой-угодно: правильной или неправильной,
но в основном - приводящей к программному сбою

Хмм.
Может я как-то не так говорю, моя программа не осуществляет запись в адресное пространство основной программы, она осуществляет чтение данных из ее адресного пространства.
Вот минимальный код, приводящий к проблеме.
Пардон, на дельфи

где idoc3d интерфейсная ссылка



Поставил брейкпоинт на данные - в строке чтения значения осуществляется запись в тело объекта со смещением 4 байта 
Сначала вызывается дельфовая DispCallByID, затем DispCall, затем неименованная функция библиотеки MFC42u.dll, которая и осуществляет запись . После длительных раздумий решил, что COM-среда рассматривает кусок COM-объекта как область памяти для некоторых своих переменных и даже вызов немодифицирующей объект функции приводит к изменения в этой области памяти.

Это все объясняет, а как я говорил вначале в случае записи этого бы не проихошло

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

сильно сомневаюсь, что это делает "COM-среда", т.к. эта среда, если мы об одном и том же говорим, 
заканчивается сразу за вызовом IDispatch::invoke

конечно, за пределами 4 первх байт объекта могут начинаться непосредственно данные "черного ящика",
запись туда вполне могла бы делать "отлаживаемая среда",
т.е. реальный класс COM объекта вполне может наследоваться от какого-то класса MFC-шного COM объекта,
типа "трейсера" (tracer) во время отладки, и коннечно данные этого трейсера будут расположены ранее в пределах объекта

в принципе, да, если приравнять этого предка к "COM-среде", то ход мыслей верный,
т.е. да - "СOM-среда рассматривает кусок COM-объекта как область памяти для некоторых своих переменных",
т.к. этот кусок объекта есть собственность самой этой среды, она может делать с ним что хочет, хоть писать во время чтения )

Не то и не другое   
Твой программа осуществляет ВЫЗОВ виртуального метода от уничтоженного объекта.

Все общение с ЛЮБЫМ COM объектом (а уж тем более с IDispatch) осуществляется ТОЛЬКО через vtbl, так уж COM устроен   
А уж метод (даже если это реализация чтения проперти) может сделать что угодно, например проверить валидность объекта и даже обновить в нем что захочет   

Это все понятно.
Я смотрел реализацию метода ksDocument3D:Reference (точнее, все вызовы dll-ки, где реализован функционал ksDocument3D расположенные в строке

)
Они не модифицируют объект. 
Подумай сам - метод, возвращающий целое число модифицирует объект?? Где интуитивная понятность? Где прозрачность кода?? Такого просто не может быть.
GremlinProg, предложил интересное объяснение. Если я правильно его понял, то есть MFC-класс, потомок IDispatch, который переопределяет метод invoke. ksDocument3D (к слову сказать, реализация ksDocument3d собиралась компилятором идущим с visual studio 6.0, так что есть все шансы что использовалась mfc) использует его. И это переопределение пишется в свой кусок ksDocument3D в случае чтения данных. Странно, непонятно, но оно это делает. Зачем надо хранить информацию о том, что вот мол, меня прочитали. 
Дальше - больше. Com-объект сидел где-то в хипе основной программы. Умер. Старательная обертка idispatch зафиксировала чтение данных. Записала в труп. Прошла новая операция с хипом. Хип проверил целостность блоков. Обнаружил запись. Дальши либо отказался сотрудничать, либо забацал исключение. Отсюда вывод информационного сообщения.
По большому счету все это укладывается в канву - не работай с умершим объектом. Просто мне было интересно.

может что-то типо автодокументации,
т.е. после запуска A, нужно выполнить B, потом прочитать C, чтобы выполнить D

стейт-машина, по типу:

Проблема в том, что мог быть вызван уже не ksDocument3D:Reference   Т.к. вызов идет через vtbl, а указатель на нее хранится в уже освобожденной части хипа, то кто то мог после удаления объекта (но до выхова ksDocument3D:Reference) заказать память, получить кусок памяти, где раньше был объект и переписать то место, где был указатель на vtbl.
GremlinProg предложил такую реализацию, ты же сам писал:

да, вполне возможно,
и раз уж dizzy1984, так глубоко залез в это,
то может проверить по одинаковым ли адресам прыгает программа до и после Release,
т.е. по крайней мере, посмотреть куда прыгает до...

я вообще не вижу ничего криминального в том, что при чтении, и даже из константы ( если вдруг ) кто-то что-то в нее пишет,
в конце-концов, такое поведение легализовано в C++, на уровне модификатора mutable,
а в Pascal/Delphi (ранних версий, по крайней мере) этому даже внимание не уделяется

на то они и свойства, чтобы скрывать сложную и/или неоднозначную логику доступа к полю