-
Писал RoboWarz на этой версии, так я почти 5 часов не мог найти глюк, ацесс виолатион вылетал при освобождении бота, уже голова деревянная стала, ну нет там ошибки, не должно такое быть, но вылетало. Когдла уже совсем соображать перестал, догадался на старой версии 1.0.10 скомпилировать, всё заработало как надо. Для проверки исходники RoboWarz в этой ветке: http://pda.delphimaster.net/?id=1087913563&n=3&web=1И ещё почему-то в DLL функции не может строку (имя бота) передать, нулевая идёт, хотя на старой версии работает.
-
Может, чтобы лишнюю головную боль другим не делать, сначала поробуешь локализовать баг, сделать мини-демонструшку? К слову: пересобраны-то под 1.9 все dll-и? А то ведь за время разработки 1.1/1.9 calling conventions по умолчанию менялись. Это, конечно, лишь попытка "телепатии" :^)
-
По поводу телепатии я же указал где проблема и исходники там лежат. Проблему локализовывал, если удаление комментируешь, то не вылетает. Сначала всё на 1.9.4 делал, но после обнаружения ошибки всё компилировал на 1.0.10.
В модуле RobowarUnit.pas процедура DelBot. Где конкретней в той процедуре вылетает я не знаю - не знаю как DLL-ки отлаживать. Пробовал вместо New Dispose делать GetMem, FreeMem так же вылетает.
-
Может, менеджеры памяти оказываются разными? Всегда ли "бот" создается в той же dll, в которой потом уничтожается?
-
Может реализация dll какая-то сранная у них стала. В простой программе New Dispose раотает прекрасно. Что интересно, после Dispose обращение по этому указателю не вызывает ацессвиолатион, хотя по идее должна :) Пробная программка:
program Test;
TYPE
PTest = ^TTest;
TTest = record
A : Cardinal;
B : Longint;
C : Pointer;
end;
Var
P1,P2 : PTest;
begin
New(P1);
P2:=P1;
P2^.A:=100;
P2^.B:=-100;
P2^.C:=P2;
WriteLN(P1^.A);
WriteLN(P2^.A);
Dispose(P2);
WriteLN(P1^.A);
WriteLN(P2^.A);
ReadLn;
end.
Менеджер памяти видимо изменили, в версии 1.9.4 ацессвиолатион-а в данном примере нет, показывает нулевое значение после Dispose указателя, а в версии 1.0.10 программа вылетает.
-
> Всегда ли "бот" создается в той же dll, в которой потом
> уничтожается?
Все объекты обрабатываются одной dll - RobowarUnit.pas, там же создаются и удаляются, она всем хозяйством заведует.
-
Стоп. А кто сказал, что после dispose значение указателя должно стать nil? BTW, изменить new/dispose на GetMem/ReallocMem(0)не пробовал? Или явно после Dispose присвоить указателю nil?
-
Удалено модератором
Примечание: дубль
-
> А кто сказал, что после dispose значение указателя должно
> стать nil?
Никто не сказал. Причём тут это? Здесь должен быть ацессвиолатион, а его нет. Там после освобождения памяти попытка чтения числа из освобождённой структуры идёт, в старом как положено ацессвиолатион выходит, а в новом намудрили что-то.
> показывает нулевое значение после Dispose указателя
В этом предложении я имел ввиду, что
Dispose(P2);
WriteLN(P1^.A);
на экран ноль выводит, криво сказал просто. :)
-
Блаародный дон забыл, что менеджер памяти он использует не виндовый. Вот после HeapFree/LocalFree точно был бы AV.
-
Не нужно про благородных донов, проблема описана в первом посте, а код вышеприведённый показывает, что изменён менеджер памяти.
-
Только вот из того, что изменен, глючность еще не следует. Хотя, конечно, подозрения возникать могут с бОльшим основанием. Но, вроде бы, посмотреть-то именно баг надо, а не поведение менеджера памяти при заведомо некорректных режимах работы. Давайте-ка попробуйте сделать мини-пример, который иллюстрировал бы именно описанный в [1] баг, а не что-то другое. Честно говоря, отладкой игрушки этой целиком мне заниматься не хочется.
-
-
Сегодня пересобрал компилятор и RTL 1.9.5 из последних исходников. ТестГлюк работает без глюка. Так что, видимо, баг исправили без нас :^)
|
Есть новые 
Нет новых [118784 +119][b:0][p:0.003]