Hi,

I've posted this issue on the Lazarus mailing list few weeks ago, and no breakthroughs. On the other hand, I suspect this problem could as well have to do with FPC handling strings.

I am using FPC v2.2.0 [2008/05/29] for i386 with Mac OS X v10.4.11. And this problem doesn't appear on the Win32 version.

At certain points our (large) application crashes, like when a control is about to show a hint, it raises an exception class 'External: EXC_BAD_ACCESS':

The following debug message says "Execution paused": Adress: $0000D589
Procedure: SYSTEM_TOBJECT_$__INHERITSFROM$TCLASS$$BOOLEAN File:

and breaks at line 1725 in carbonwinapi.inc:

  if not CheckDC(DC, 'GetTextExtentPoint') then Exit;

I've no clue as to why it breaks at this line, and I traced the exact crash point to line 1582 in control.inc:
Dispatch(TheMessage)

The GetTextExtentPoint is actually called 6 times with the same string and no problems, and the Dispatch is called twice after the 6th time with no problems, but crashes at the 3rd call to Dispatch.

The TheMessage has the following parameters:

{MSG=66592, WPARAM=265482992, LPARAM=0, RESULT=0, WPARAMLO=62192, WPARAMHI=4050, LPARAMLO=0, LPARAMHI=0, RESULTLO=0, RESULTHI=0}

The MSG is LM_PAINT and WPARAM is the DC.

Note: If I let another control show its hint first, it doesn't crash if the control shows its hint - it only crash every time when it's the first control to show its hint. It also crashes on some controls painting strings, but not with other identical controls with different text.

I can't reproduce the crash on a test program, so I suspect it has to do with large applications with tons of strings.

It doesn't crash randomly, but changing a string and recompile the application can make it crash in a different control.

Could FPC have troubles handling strings? And should I change our handlings of strings to a certain type of strings before setting text properties of controls?

Any clue or help is much appreciated.

Best regards,
Normann

Bent Normann Olsen wrote

I can't reproduce the crash on a test program, so I suspect it has to do with large applications with tons of strings.

It's most likely due to memory corruption in the large application caused by a bug in it.

Could FPC have troubles handling strings?

It could of course, but there are no known issues with it.

And should I change our handlings of strings to a certain type of strings before setting text properties of controls?

No.

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. 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).

Another interesting approach might be looking for Pascal support in Delta (http://delta.tigris.org/) to automatically reduce the large program to a smaller one which still demonstrates the problem.

Jonas

Hi,

Thanks for the input.

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

No, it needs live debugging.

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