[Lazarus] EXC_BAD_ACCESS, Could not access memory
Bogusław Brandys
brandys at o2.pl
Mon Apr 27 18:01:05 CEST 2009
Roland Turcan wrote:
> Hello Dmitry,
>
> Thanks for your reply, but I think, that you haven't understood me
> what I am trying to explain.
>
> I have binary contents which are copied from memory using by an
> application which is written in Delphi. I am porting an application to
> MacOS X 10.5, but I need to use the same structures as I have in
> Delphi and Kylix where "NOT PACKED" records are aligned.
>
> The fact is, that FPC compiler on intel based Mac OS X builds up
> application which contains records "packed" by 4 bytes by default.
>
> I need to get the same behavior in intel based mac os x as I have in
> other platforms.
>
> What should I do to build FPC compiler which will behave the same on
> all platforms.
>
> TRoland;
>
> <<< 27.4.2009 17:04 - dmitry boyarintsev "skalogryz.lists at gmail.com" >>>
> db> use:
> db> TYPE TMyOne = packed record
> db> First:integer;
> db> Second:extended;
> db> END;
> db> to be sure about 20 bytes boundary.
>
> db> thanks,
> db> dmitry
>
>
> db> Hello All,
> db>
> db> I have found some new information about this problem:
> db>
> db> 1.
> db>
> db> TYPE TMyOne =record
> db> First:integer;
> db> Second:integer;
> db> end;
> db>
> db> ... then the size of this object is 2*4 bytes.
> db>
> db> 2.
> db>
> db> TYPE TMyOne =record
> db> First:integer;
> db> Second:double;
> db> END;
> db>
> db> ... where I would expect 4 + 8 bytes = 12 bytes
> db> ... but the size of this object is 16!
> db>
> db>
> db> 3.
> db>
> db> TYPE TMyOne =record
> db> First:integer;
> db> Second:extended;
> db> END;
> db>
> db> ... where I would expect 4 + 16 bytes = 20 bytes
> db> ... but the size of this object is 32!
> db>
> db>
> db> So this proves me, that compiler tries to align the data structure to
> db> multiplied size of biggest element to which fit all elements.
> db>
> db> I have understood this behavior, but this happens me in these cases:
> db>
> db> 1. Delphi 7
> db> 2. Kylix 3
> db> 3. Lazarus on Ubuntu
> db> 4. Lazarus on PowerPC Mac OS X 10.5
> db>
> db> but on Intel Based Mac OS X 10.5 Mini with Intel Duo 2 Core it
> db> DOESN'T. Therefore I have problems with parsing of binaries back to
> db> memory.
> db>
> db> I don't expect CPU specific problem, otherwise it would not work
> db> active projects, therefore I think it must be compiler specific
> db> problem.
> db>
> db> Do you have any idea?
> db>
> db> Thanks in advance.
> db>
> db> Greetings, TRoland;
> db>
> db>
> db> <<< 25.4.2009 9:43 - Roland Turcan "konf at rotursoft.sk" >>>
> RT>> Hello Diettrich,
> db>
> RT>> To tell the truth this code and style I got from previous developer
> RT>> and I really don't know why he decided to get the size of header from
> RT>> the binary instead of getting its size. The fact is, that this
> RT>> "optimistic variant" of coding is on many places. :-|
> db>
> RT>> TRoland;
> db>
> RT>> <<< 24.4.2009 19:56 - Hans-Peter Diettrich "DrDiettrich1 at aol.com" >>>
> HPD>>> Roland Turcan schrieb:
> db>
>>>>> BB> How is HeaderLen declared ?
>>>>>
>>>>> Stream.Read (HeaderLen, SIZEOF (HeaderLen));
>>>>>
>>>>> where information header's length is stored into binary.
> db>
> HPD>>> The you should verify that HeaderLen <= SizeOf(FHeader), before
> HPD>>> Stream.Read (FHeader, HeaderLen);
> db>
> HPD>>> Otherwise this statement will overwrite the following FItem data, with
> HPD>>> the fatal consequences you already experienced.
> db>
> HPD>>> When a header will ever change in size (or structure), it's wise to
> HPD>>> store a version number in the data files. Then you can read the stored
> HPD>>> header data into the exactly applicable header type (record), and
> HPD>>> convert that record into the current THeader definition, field by field.
> db>
> HPD>>> DoDi
>
>
>
Check docs. Also http://wiki.freepascal.org/Mode_MacPas and
http://bugs.freepascal.org/view.php?id=13187
Cannot help further, because don't know Mac OS.
Regards
Boguslaw
More information about the Lazarus
mailing list