On 26 Jun 2008, at 15:07, Bent Normann Olsen wrote:
Another option is -gh to turn on memory debugging, possibly also
adding
"keepreleased:=true" to your program initialisation code (but in that
case watch the memory usage, as no memory will really be released in
that case).
Now if I use the -gh option, it doesn't crash at the usual point, but
crashes on exiting application at:
Line 2567 in carbonwinapi.inc:
if not CheckDC(DC, SName) then Exit;
And that is in a function for SelectObject, which is a little
different from
the GetTextExtentPoint function.
When it crashes on exiting (with -gh option) I can get this report -
it
doesn't tell me much, but maybe it's useful for more experient
programmers:
No, it needs live debugging.
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x00000001 ebx: 0x00000009 ecx: 0x00000001 edx: 0x0070e6b0
edi: 0x0000000e esi: 0xbfffd278 ebp: 0xbfffd218 esp: 0xbfffd190
ss: 0x0000001f efl: 0x00010206 eip: 0x0000cfe9 cs: 0x00000017
ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037
[snip]
I'm not sure, but doesn't the registers show invalid addresses?
Registers do not always have to contain valid addresses.
I wish I
could debug the application and watch how certain areas of memory is
being
change, when and how.
You can use watchpoints in gdb to do this (but best only watch regions
of at most 4 bytes large and not too many at a time for performance
reasons).
The strange is that this application works fine on Delphi and
Lazarus for
Win32, and occurs only on Lazarus for Mac OS X/Carbon.
It regularly happens that generic bugs only appear on one particular
platform for a myriad of reasons (although it could of course also be
a bug in the Carbon LCL interface).
Jonas
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
