Try filling LogData with binary zeros after the Getmem & before the assign.
FillChar (LogData^, sizeof(TLogData), 0);
I believe the uninitialized memory is messing up the compiler magic
associated with the dynamic array.
Any reason the local Tlogdata record is referenced via a pointer?
I suspect the following will also work:
procedure TUserClass.Log(const LogType: TLogType; const Args: array of
const );
var
LogData: TLogData;
begin
LogData.LogType := LogType;
LogData.LogArgs := CreateConstArray(Args);
// ... do some other stuff with the LogData item finally calling
end;
Cheers
On 26/08/2011 1:49 a.m., David Moorhouse wrote:
> Hi Peter
>
> Been there done that :)
>
> The function call is fine. It is the assignment that causes the AV -
> because the "bucket" is too small.
> Assigning it with 16 bytes fixes the problem, regardless of how many
> items the array holds.
>
> I smell compiler magic in the background.
>
> Cheers
>
> D
>
> On 25/08/11 17:29, Peter Ingham wrote:
>> Another attempt to reply...
>>
>> First thing to do is determine if the crash occurs in the procedure call,
>> on the subsequent assign, or in between.
>>
>> Give this a try:
>> procedure TUserClass.Log(const LogType: TLogType; const Args: array of
>> const );
>> var
>> LogData: PLogData;
>> TempArgs : TConstArray;
>> begin
>> // size of record TLogData does not work
>> GetMem(LogData, sizeof(TLogData));
>> LogData.LogType := LogType;
>> // blows up on one of these lines
>> TempArgs := CreateConstArray(Args);
>> LogData.LogArgs := TempArgs;
>> // ... do some other stuff with the LogData item finally calling
>> FreeMem
>> end;
>>
>>
>> Regarding the size of a dynamic array, like a string variable, the
>> variable (LogArgs in this case) is the size of a pointer (i.e. 4 bytes
>> for Win32). If the pointer is non-zero, it points to a structure which
>> includes the adjacent array elements preceded by a length.
>>
>> One thing to watch out for is that Getmem does not clear the allocated
>> memory, so LogData after the Getmem call will contain any old rubbish.
>> The reference to LogData.LogArgs in the assignment may be
>> dereferencing a non-zero pointer& attempting to use whatever it
>> contains.
>>
>> Cheers
>>
>>
>> On 25/08/2011 11:40 a.m., David Moorhouse (DUG) wrote:
>>> I have the following code snippet
>>>
>>> <code>
>>> type
>>> PConstArray = ^TConstArray;
>>> TConstArray = array of TVarRec;
>>>
>>> function CreateConstArray(const Elements: array of const): TConstArray;
>>>
>>> type
>>> TLogType = (ltError, ltWarn, ltInfo);
>>> PLogData = ^TLogData;
>>> TLogData = record
>>> LogType: TLogType;
>>> LogArgs: TConstArray;
>>> end;
>>>
>>> ....
>>>
>>> procedure TUserClass.Log(const LogType: TLogType; const Args: array of
>>> const );
>>> var
>>> LogData: PLogData;
>>> begin
>>> // size of record TLogData does not work
>>> GetMem(LogData, sizeof(TLogData));
>>> LogData.LogType := LogType;
>>> // blows up on next line
>>> LogData.LogArgs := CreateConstArray(Args);
>>> // ... do some other stuff with the LogData item finally calling
>>> FreeMem
>>> end;
>>>
>>> function CreateConstArray(const Elements: array of const): TConstArray;
>>> var
>>> I: Integer;
>>> begin
>>> SetLength(Result, Length(Elements));
>>> for I := Low(Elements) to High(Elements) do
>>> Result[I] := // assign a TVarRec here
>>> end;
>>> </code>
>>>
>>> The code that assigns the memory only assigns 8 bytes - and an access
>>> violation ensues. If I replace the call to "sizeof" with the number 16,
>>> the code works fine.
>>>
>>> My understanding of dynamic arrays was that the compiler created a 4
>>> byte
>>> field before the first element that contained the length of the array.
>>>
>>> So why does the sizeof function not reflect this ? And why do I
>>> need 16
>>> bytes not 12 (4 for LogType + 4 for length of array + 4 for array
>>> pointer)?
>>> Also regardless of the number of items in the open array parameter, 16
>>> bytes works, so it does not relate the length of the TConstArray.
>>>
>>> Your thoughts ?
>>>
>>> David
>>>
>>>
>>>
>>> _______________________________________________
>>> NZ Borland Developers Group - Delphi mailing list
>>> Post: delphi@delphi.org.nz
>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>> Unsubscribe: send an email to delphi-requ...@delphi.org.nz with
>>> Subject: unsubscribe
>>>
>>
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi@delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
> unsubscribe
>
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe
