Не могу разобраться с выгрузкой Dll

← →
Starkom (2002-06-04 08:29) [0]

Хоть убей, не могу понять причину, по которой прога валится при FreeLibrary. Перед этим все нормально - происходит LoadLibrary, оттуда вызывается функция через GetProcAddress. А потом все падает при выгрузке.

← →
MBo (2002-06-04 08:32) [1]

вероятно, в программе ошибка ;)

← →
Starkom (2002-06-04 08:36) [2]

Да нет, ошибка где-то в Dll, но я не могу понять где. Может кто-нибудь подскажет вероятные причины.
Кстати, эта Dll сама активно использует Load(Free)Library других Dll"ек.

← →
Starkom (2002-06-04 09:34) [3]

Подскажите, хотя бы какие ресурсы используются при загрузке Dll, и как их очищать при выгрузке.

← →
Игорь Шевченко (2002-06-04 09:42) [4]

Код бы посмотреть...

← →
Starkom (2002-06-04 10:07) [5]

код проги -
type
ProcType = function(params):PChar; cdecl;
...
libHnd := LoadLibrary ("lala.Dll");
proc := procType(GetProcAddress (libHnd, pchar("LalaFunc")));
proc (lalaparams); //происходит успешный вызов функции;
if not FreeLibrary(libHnd) then //валится на этой строчке
ShowMessage(GetLastError());

могут быть ошибки в синтаксисе, но смысл ясен. А код Dll физически не смогу показать - там архив исходников на 500 Кб.

← →
Игорь Шевченко (2002-06-04 10:11) [6]

С соглашениями о вызовах у вас точно все нормально ?
Я насчет cdecl...

← →
Starkom (2002-06-04 10:19) [7]

function LalaFunc (params): boolean; cdecl; - так описано в коде Dll. По-моему, если бы вызов функции был неправильный, то она работала бы неправильно (параметры бы, по идее, воспринялись бы неправильно), либо вообще бы не работала. А у меня работает правильно.

← →
MBo (2002-06-04 10:26) [8]

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

← →
Hate that never dies (2002-06-04 10:28) [9]

>> Starkom:
>> Кстати, эта Dll сама активно использует Load(Free)Library других Dll"ек.

В блоке begin...end. выгружаемой библиотеки попробуй сделать явное Free всех библиоек, которые ты LoadLibrary в этой самой библиотеки.
Ошибка возможно происходит из-за того, что библиотека не может корректно освободить захваченные ресурсы.

← →
Starkom (2002-06-04 10:28) [10]

хмм, и как явно очищать стек?

← →
Hate that never dies (2002-06-04 10:30) [11]

SORRY/
Конечно не в самом begin...end, а в ProccessDettach

← →
MBo (2002-06-04 10:30) [12]

явно - не надо, лишь бы совпадало соглашение

← →
Игорь Шевченко (2002-06-04 10:36) [13]

ShareMem используется в DLL и в EXE ?

← →
Starkom (2002-06-04 10:37) [14]

хмм, а что такое ProcessDetach, в хелпах такого нет.

← →
Starkom (2002-06-04 10:39) [15]

да, ShareMem и там, и там.

← →
Игорь Шевченко (2002-06-04 10:47) [16]

А в отладчике посмотреть ESP до вызова функции из DLL и после ?

← →
Starkom (2002-06-04 10:51) [17]

сама ошибка - raised too many consecutive exceptions: access violation at 0x00: read of address 0x00

← →
Starkom (2002-06-04 10:54) [18]

2 Игорь: А что в этом, ESP хранится?

← →
Григорий Ситнин (2002-06-04 10:58) [19]

2 Starkom: А в ваших DLL, случайно, не используется модуль SysUtils? Попробуйте его выключить из uses. Возможно, проблема исчезнет.

← →
oomneeq (2002-06-04 11:03) [20]

>сама ошибка - raised too many consecutive exceptions: access violation at 0x00: read of address 0x00
Application переприсваиваешь?

← →
Starkom (2002-06-04 11:07) [21]

2 Григорий: хмм, SysUtils используется почти везде и без него будет очень тяжко. А с ним бывают проблемы?

← →
Starkom (2002-06-04 11:13) [22]

2 oomneeq: нет, вроде. В некоторых местах вызывается Application.ProcessMessages, да при создании компонентов в качестве овнера суется Application

← →
Игорь Шевченко (2002-06-04 11:15) [23]

ESP - это указатель стека. Регистр такой. View/CPU Window до вызова функции из DLL и после

← →
Starkom (2002-06-04 11:27) [24]

Нет, со стеком все нормально.

← →
Игорь Шевченко (2002-06-04 11:36) [25]

Если со стеком все нормально, то можно посмотреть, что происходит в finalization секциях unit"ов, используемых в DLL. Как своих, так и стандартных.
А вообще, без кода беременность на расстоянии диагностировать крайне затруднительно :-)

← →
Starkom (2002-06-04 12:11) [26]

хмм, finalization секция только одна и в ней ничего страшного нет. в стандартных модулей слишком много.

← →
oomneeq (2002-06-04 12:54) [27]

>Starkom (04.06.02 11:13) ...
>... да при создании компонентов в качестве овнера суется Application

А чей это Application? DLLcкий или главноприложенческий?
Cтоит проверить, не уничтожаешь ли ты к примеру явно такие компоненты в неподходящий момент.
Неподходящим моментом может быть когда Application находится в состоянии csDestroying - он тогда полуживой.
А эта полуживость может быть чревата например тем, что такой Application Exception"ы нормально уже не ловит.
Короче копай в ту сторону, раз уж не приводишь исходник.

← →
Игорь Шевченко (2002-06-04 13:30) [28]

А чей Application используется в качестве Owner"а компонент ?
Application из DLL или Application из EXE ?

← →
Starkom (2002-06-05 21:45) [29]

все оказалось намного проще - приложение компилялось без дурацкой галочки build with run-time packages, а DLL с ней. :)

Не могу разобраться с выгрузкой Dll Найти похожие ветки