[fpc-pascal] Carbon: GetTextExtentPoint and Access Violation (major show stopper)

[Jonas Maebe]

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