Пишу джаббер клиент и столкнулся с неизвестной, и ранее мне не встречавшейся проблемой. При закрытии программы, возникает ошибка 
 
прошелся в деббагер до этой ошибки, она оказалась в файле "GETMEM.INC". И что еще удивительно, это то, что при включении use dynamic RTL и отключенном runtime packages ошибка исчезает. Мистика или какая то изученная вещь?    Направте меня на путь джедая.

Второе.
Отключение use dynamic RTL говорит компилятору включить менеджер памяти (ф-ции выделения и освобождения памяти) непосредственно в exe-шник (или dll-ку). Если exe-шник использует какие-либо dll-ки, которые собраны с флажком use dynamic RTL, то в программе получается 2 менеджера памяти - один внешний (borlandmm.dll), второй - вшитый в exe. Может возникнуть ситуация (а она, судя по всему и возникает), в которой один менеджер выделил память, а второй пытается освободить.
Такое может быть и если в dll-ке отключен use dynamic RTL - всё равно 2 менеджера - один встроен в exe, другой - в dll.

Короче, отключать use dynamic RTL можно только если у тебя простейшая helloWord'ная программа. Чуть сложнее - низя.

borisbn, то что изучено, это меня радует   

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

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

Мне кажется, что вы пытаетесь обратиться к какому-то объекту во время разрушения формы.
Проверьте все свои деструкторы на наличие таких обращений. Так же, если вы переопределили оконную процедуру, то при обработке событий, лучше всё обернуть в:

Плюс, при закрытии формы, нужно останавливать все закачки и потоки (особенно те, из которых идёт обращение к VCL).

Это сообщение отредактировал(а) artsb - 24.7.2011, 01:15

Или если программа не использует никаких dll (ну кроме системных   ), как видимо у ТС и есть   


А что в стеке до GETMEM.INC ?

artsb,
Сейчас пробегусь по коду, проверю все еще раз. Может действительно допустил где то ошибку, портящую мне жизнь теперь.

xvr, 

 

А где смотреть? в "Call stack"? перед тем как действие перешло в getmem.inc?

И еще, если например не делать ClientSocket->Open(); закрывается нормально, без ошибок.

Похоже, что у вас ClientSocket работает в отдельном потоке. И вы этот поток не останавливаете при закрытии формы. А в обработчиках ClientSocket, у вас идёт обновление какого-нибудь Label'а. И происходит так, что Label уже "умер", а поток пытается до него достучаться.
Плюс проверьте обработчики событий ClientSocket.

глупости все это.

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

это никак не влияет на AV

Именно. В момент слома.

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

Это сообщение отредактировал(а) borisbn - 25.7.2011, 17:49

а такое происходит когда программер код через одно место сваял

пример: основная программа передаёт в dll-ку свой TForm в качестве Parent'а и Owner'а. В dll-ке создаётся TFrame, который кладётся на Parent'а и делает его своим Owner'ом. По окончании программы Owner удаляет всех "детей", в том числе и того, который создан в dll. Если отключить use dynamic RTL, то в dll-ке память под TFrame выделит свой менеджер, а удалит его в основной программе - другой. При включенном же use dynamic RTL всё будет делать один манагер.
Такой способ Ownership-ства - вполне стандартная вещь в VCL, и тот, кто его использует - вовсе не криворукий. Вот VCL-ю не мешало бы проверять, чтоб такой ситуации с двумя менеджерами не было в принципе. Не знаю как... в других системах ведь как-то проверяют

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