END出错的原因是清除堆栈中的局部变量出错。
这种容易出错的变量都是DELPHI自维护的类型,最主要的是STRING
而发生这样的原因最主要又是因为数据被破坏
打个比方:
procedure testerror;
type pFloat=^Real;
Var A:Integer;
B:String;
begin
B:='123';
pFloat(@A)^:=10101;
end;
等到你执行到END以后就出错了,原因是释放B出错,因为B的地址已经被覆盖了。
当然一般来说我们是不会如此低级错误,但是在使用其他的时候就未必了:
打个比方:
procedure testerror;
type pFloat=^Real;
Var A:Array[0..1023] of integer;
B:String;
i:Integer;
begin
B:='123';
for i:=0 to length(A) do //Maybe somebody wrote as for i:=1 to length(A)
begin
A:=i;
end;
end;
象这种访问数组越界的少-1的事情是经常发生的笔误,这同样会引发END后出错。
同样的错误还可能容易发生在:
Socket.recvbuf(Buf,Count)
打个比方
procedure testerror;
type pFloat=^Real;
Var A:String;
B:String;
begin
B:='123';
setlength(A,Socket.RecvLength);
Socket.RecvBuf(A,Socket.RecvLength)
end;
这样也会发生这样的错误,也许YB_U...遇到的问题就是如此,
我们往往忘记写成Socket.RecvBuf(A[1],Socket.RecvLength),结果B的位置又被覆盖了
还有一种情况也会导致这样的错误,那就是DLL之间使用了STRING类型而且未有使用SHAREMEM,
这个情况我相信大家都已经很清楚了,就不多说了。
千万别“对DELPHI越来越失望了”,DELPHI确实不是一个完美的东西,尽管我也有时候
对DELPHI编译上的一些怪异的处理比较失望,但是倘若你真正掌握了它,把其当成一个
不错的OBJECT PASCAL编译器还是很不错的,我确实对学C++很厌恶,好在还有一个DELPHI。