[SOLVED] OS X: Exception after final end in FinalizeUnits.

[tk]

Hi, having strange problem under OS X (Yosemite on Vmware).
The app runs normally but generates exception SIGSEGV after final end in System.FinalizeUnits on line:

Code: [Select]

00028763 8b8380194c00             mov    0x4c1980(%ebx),%eax

Project xxx raised exception class 'RunError(216)'.
At address 28768.

Stack trace:

Code: [Select]

#0 SYSTEM_$$_FINALIZEUNITS at :0
#1 SYSTEM_$$_INTERNALEXIT at :0
#2 SYSTEM_$$_INTERNALEXIT at :0
#3 ?? at :0
#4 SYSTEM_$$_FPC_SYSTEMMAIN$LONGINT$PPCHAR$PPCHAR at :0
#5 _start at :0
#6 start at :0

I've put breakpoint to the beginning of FinalizeUnits, there it is still ok, then step through single instructions and get the exception. No unit finalization is actually called.

Empty project or simple demo project run and terminate normally.
The app runs normally on Win and Linux. Only on OS X this problem.
Problem persists even in release mode and when the app is launched outside of Lazarus.

Must have been some cleanup issue but how to find the reason.
Thank you for any ideas here.

[tk]

More info to this:
Sth. must be wrong here, because on line

Code: [Select]

00028763 8b8380194c00             mov    0x4c1980(%ebx),%eaxI need three commands Step Into Instruction before the exception is raised. The EIP on these 3 steps has values:
28763,
28765,
28768.
When EIP is 28768 the exception is raised.

Next code is:

Code: [Select]

00028763 8b8380194c00             mov    0x4c1980(%ebx),%eax
00028769 83780400                 cmpl   $0x0,0x4(%eax)
0002876D 7fc1                     jg     0x28730 <SYSTEM_$$_FINALIZEUNITS+16>
0002876F 8b1c24                   mov    (%esp),%ebx

Looks like there is another assembly executed than shown.

EDIT: All options in the Config and Target tab are set on default. And there is no addition and override defined.

[molly]

Runtime error 216:

216 General Protection fault
The application tried to access invalid memory space. This can be caused by several problems:
- Dereferencing a nil pointer.
- Trying to access memory which is out of bounds (for example, calling move with an invalid length).

try to add -gl to fpc command so that you can produce a stacktrace that is able to help you trace back where things originate from.

Edit:
Oh, i guess you already did ?

Sorry, i don't have much experience with OS-X and debugging topic. If you compile from lazarus, then try an switch on every debug related switch in the project options that is possible, including range checking, overflow etc, debugging symbols, lineinfo and try to run the program again.

The moment you are able to see a 'normal' routine produced by yourself, try look it up in the source-code, set a breakpoint and step through it to see what parameters  are given to those functions.

[tk]

If you compile from lazarus, then try an switch on every debug related switch in the project options that is possible, including range checking, overflow etc, debugging symbols, lineinfo and try to run the program again.

Thank you that helped me indeed!

I realized that some memory access bug has modified the code memory but could not find it.
Finally after turning all those switches the compiler warned me about a clear bug (is a copy paste bug):

Code: Pascal  [Select][+][-]

1.  
2. var
3.   Ctrl: TControl;
4. ...
5.   if (Ctrl is TsComboBox) then
6.     begin
7.       TsComboBox(Ctrl).SkinData.CustomColor := B;
8.  
9.       if B then
10.         TsEdit(Ctrl).Color := cHighlightColor
11.       else
12.         TsEdit(Ctrl).Color := clWhite
13.     end        
14.  

But still there is bug somewhere because some cleanup code in System.System_exit fails with another exception.
I'll try to disable certain app functions (if possible) to find it.

Interesting is that despite these bugs the same app run normally both under Win and Linux and no customer ever claimed 

[molly]

Thank you that helped me indeed!

You saved me by your own expertise *phew-wipes-off-sweat* so thank you 

I'll try to disable certain app functions (if possible) to find it.

Biggest hurdle is indeed being able to locate where the bug originates from. being able to reproduce with the simplest of code/example helps tremendously.

Dunno if it is informative: if all else fails i usually resort to using simple WriteLn's or DebugLn's to be able to determine what still works and what not or to rule out certain functionality in order to be able to pinpoint exact locations. Very oldschool, but it survived the sands of time :-)

nteresting is that despite these bugs the same app run normally both under Win and Linux and no customer ever claimed

Thank you for the smile on my face. Sometimes it's a wonderful mysterious world we live in.

Congratz on the squash and i wish you a good luck with finding the other(s).

[tk]

But still there is bug somewhere because some cleanup code in System.System_exit fails with another exception.
I'll try to disable certain app functions (if possible) to find it.

I could isolate even this problem but it is completely another issue, I'll write another topic about this.
Marking this issue as solved.