ludob,
Yes i know the try, except does only mask the issue. But i was forced to do this to see what happens with the other tests. Like i wrote is that a strange not 100% reproduceable exception which does make me slightly grazy. I was wondering very long times why and how this can happen. But i'm not a compiler hero which does understand asm code and i was equal not able to find the origin of thes strange issues. My impressen since long times are the disabled range-checks or the huge count of connections. It could also be an issue with Zeos 'em selves. I can not realy say what happens there and why either the stack is vinny nilly or firebird. I love the FB engine. And i use it in several project of my companies with Zeos. Everything is stable. I never ever had issues like this.
Here we've the problem that the FPC (in my mind) has a different behavior to delphi with such exception handling. Yes indeed the GUI makes trouble with the progressbar. So i commented this line out on my sources(no solution, i know) and later i switched to the batch-mode because i use WinMerge to check the fails and exception with previous releases. Mark the project-Manager does the same weekly. But i was equal not able to locate the issue with this progressbar. I made a try and except around and did declare some vars to copy the values in the except parts. This was no problem. All values where easiely able to copy but again in exceuting the algorithym for the position of the bar it crashing again and again. I don't know why.. The only thing i know is that this trouble only happens if firebird+fpc is involved.
There are other things too which i can't explain like this:
Code: Select all
function TZRowAccessor.GetBlobObject(Buffer: PZRowBuffer;
ColumnIndex: Integer): IZBlob;
var
BlobPtr: PPointer;
NullPtr: {$IFDEF WIN64}PBoolean{$ELSE}PByte{$ENDIF};
begin
BlobPtr := PPointer(@Buffer.Columns[FColumnOffsets[ColumnIndex - 1] + 1]);
NullPtr := {$IFDEF WIN64}PBoolean{$ELSE}PByte{$ENDIF}(@Buffer.Columns[FColumnOffsets[ColumnIndex - 1]]);
{$IFNDEF FPC}
if NullPtr^ = {$IFDEF WIN64}false{$ELSE}0{$ENDIF} then //M.A. if NullPtr^ = 0 then
{$ELSE}
if NullPtr^ = 0 then
{$ENDIF}
Result := IZBlob(BlobPtr^)
else
Result := nil;
end;
{**
Sets a blob into the specified columns.
@param Buffer a row buffer.
@param ColumnIndex an index of the column.
@param Value a stream object to be set.
}
procedure TZRowAccessor.SetBlobObject(Buffer: PZRowBuffer; ColumnIndex: Integer;
Value: IZBlob);
var
BlobPtr: PPointer;
NullPtr: {$IFDEF WIN64}PBoolean{$ELSE}PByte{$ENDIF};
begin
BlobPtr := PPointer(@Buffer.Columns[FColumnOffsets[ColumnIndex - 1] + 1]);
NullPtr := {$IFDEF WIN64}PBoolean{$ELSE}PByte{$ENDIF}(@Buffer.Columns[FColumnOffsets[ColumnIndex - 1]]);
{$IFNDEF FPC}
if NullPtr^ = {$IFDEF WIN64}false{$ELSE}0{$ENDIF} then //M.A. if NullPtr^ = 0 then
{$ELSE}
if NullPtr^ = 0 then
{$ENDIF}
IZBlob(BlobPtr^) := nil
else
BlobPtr^ := nil;
IZBlob(BlobPtr^) := Value;
if Value <> nil then
{$IFNDEF FPC}
NullPtr^ := {$IFDEF WIN64}false{$ELSE}0{$ENDIF} //M.A. NullPtr^ := 0
else
NullPtr^ := {$IFDEF WIN64}true{$ELSE}1{$ENDIF}; //M.A. NullPtr^ := 1;
{$ELSE}
NullPtr^ := 0
else
NullPtr^ := 1;
{$ENDIF}
end;
This is an code extraction of the ZDbcCache unit. Totaly grazy here is the the Null byte of our rowaccessor field offsets was not readable corectly in Win64+FPC. A thread for more details:
http://zeos.firmos.at/viewtopic.php?t=3 ... c&start=45
Here i was running the delphi and fpc debugger to find the issue. I was wondering why the IsNull byte delivers always false which means i had the crash on trying to access a nilled interface. It was a very long night. But successful and Zeos was now prepared for Win64.
Ludo thank you for investing some time into these strange things. But it could be equal save your time if you point somone who is a compiler hero to this issues. They are strange, realy strange. For me not realy understandable. Eventually do we find another leak on the FPC or an Zeos. But knowing the reason would be great. I'm nobody who likes it to close his eyes and play the blind man. If i can understand an issue then i can solve this. But here i was forced to give uo a while until i find more time for this.
Michael
