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

[Bent Normann Olsen]

Hi,

Thanks for the input.

> > Any clue or help is much appreciated.
> 
> You could try compiling your program (and possibly the lcl) with -gttt
> to turn on filling local variables and out parameters with garbage,
> which may help in case the problem is an uninitialised value.

I did try -gttt, and nothing different happened.

> 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:

[snip]
Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xf0f0f0f8

Thread 0 Crashed:
0   com.company.ear50s_mac 	0x0000d949
SYSTEM_TOBJECT_$__INHERITSFROM$TCLASS$$BOOLEAN + 25
1   com.company.ear50s_mac 	0x0025ee39
CARBONINT_TCARBONWIDGETSET_$__SELECTOBJECT$HDC$HGDIOBJ$$HGDIOBJ + 41
(carbonwinapi.inc:2567)
2   com.company.ear50s_mac 	0x00194fd8
LCLINTF_SELECTOBJECT$HDC$HGDIOBJ$$HGDIOBJ + 40 (winapi.inc:751)
3   com.company.ear50s_mac 	0x001a74fc
GRAPHICS_TCANVAS_$__DESELECTHANDLES + 108 (canvas.inc:1486)
4   com.company.ear50s_mac 	0x001a7465 GRAPHICS_TCANVAS_$__SETHANDLE$HDC
+ 53 (canvas.inc:1457)
5   com.company.ear50s_mac 	0x001a755c GRAPHICS_TCANVAS_$__FREEHANDLE +
28 (canvas.inc:1508)
6   com.company.ear50s_mac 	0x001c19b1
CONTROLS_TCONTROLCANVAS_$__FREEHANDLE + 17 (controlcanvas.inc:106)
7   com.company.ear50s_mac 	0x001c18ef
CONTROLS_TCONTROLCANVAS_$__DESTROY + 47 (controlcanvas.inc:70)
8   com.company.ear50s_mac 	0x0000d435 SYSTEM_TOBJECT_$__FREE + 21
[snip]
...
[snip]
Thread 1:
0   libSystem.B.dylib      	0x900248c7 semaphore_wait_signal_trap + 7
1   com.apple.ColorSync    	0x915a96db
pthreadSemaphoreWait(t_pthreadSemaphore*) + 35
2   com.apple.ColorSync    	0x915c3dec CMMConvTask(void*) + 60
3   libSystem.B.dylib      	0x90024227 _pthread_body + 84

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0xf0f0f0f0  ebx: 0xf0f0f0f8  ecx: 0xf0f0f0f0  edx: 0x007116b0
  edi: 0x0033bb18  esi: 0x0f1782f8  ebp: 0xbffff958  esp: 0xbffff8d0
   ss: 0x0000001f  efl: 0x00010282  eip: 0x0000d949   cs: 0x00000017
   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037

Binary Images Description: 
[snip]


When it crashes instantly (with no -gh option), I can get this report:

[snip]
Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000009

Thread 0 Crashed:
0   com.company.test1a_mac   	0x0000cfe9
SYSTEM_TOBJECT_$__INHERITSFROM$TCLASS$$BOOLEAN + 25
1   com.company.test1a_mac   	0x0025b029
CARBONINT_TCARBONWIDGETSET_$__GETTEXTEXTENTPOINT$HDC$PCHAR$LONGINT$TSIZE$$BO
OLEAN + 41 (carbonwinapi.inc:1725)
2   com.company.test1a_mac   	0x0019132e
LCLINTF_GETTEXTEXTENTPOINT$HDC$PCHAR$LONGINT$TSIZE$$BOOLEAN + 62
(winapi.inc:456)
3   com.company.test1a_mac   	0x001a4b42
GRAPHICS_TCANVAS_$__TEXTEXTENT$ANSISTRING$$TSIZE + 98 (canvas.inc:1589)
4   com.company.test1a_mac   	0x001a4b6d
GRAPHICS_TCANVAS_$__TEXTWIDTH$ANSISTRING$$LONGINT + 29 (canvas.inc:1600)
[snip]
...
[snip]
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? I wish I
could debug the application and watch how certain areas of memory is being
change, when and how.

I do believe the memory used is somehow getting corrupted, and I'm in need
of how to trace this. I've checked the application, but all seem to be fine.

The strange is that this application works fine on Delphi and Lazarus for
Win32, and occurs only on Lazarus for Mac OS X/Carbon.

I tried to recompile Lazarus with gtk and gtk 2, but it began to have
trouble finding interface files. I will try this and see if this error can
be isolated to Carbon.

> Jonas

Regards,
Normann