How to find this bug?

[JimKueneman]

I have an application currently developing on High Sierra and 2.2.4.  I get this random crash (happens a lot so can reproduce) but it only shows an OSX dialog:

Error:
   Project xxx raised exception class
   'Process stopped with reason: signal SIGABRT'.

   At address 7FF6B32FB66

it happens at random times (but only when I have TCP data transfers with Indy) and I am at a loss on how to pinpoint where it is occuring... anyone have any suggestions/tip/tricks to figure this out?

Thanks,
Jim

[Martin_fr]

The address means it is likely in some library or the kernel.

But when that happen and you pressed "break" (or "ok"?) then you can open from the menu: View > Debug Windows > Call stack.

That will likely show you where in your code (or Indy) the lib/kernel was called.

[JimKueneman]

It never show me a trace to the program code. 

#0 __pthread_kill at :-1
#1 pthread_kill at :-1
#2 abort at :-1
#3 abort_message at :-1
#4 default_terminate_handler at :-1
#5 _objc_terminate at :-1
#6 std::__terminate at :-1
#7 __cxa_rethrow at :-1
#8 objc_exception_rethrow at :-1
#9 CFRunLoopRunSpecific at :-1
#10  at :0
#

[JimKueneman]

Will try/finally/except blocks trap this sort of exception?   It seems to happen right around the same place in my stress test.  If I add handlers around blocks of code will they be triggered with this type is issue?

It requires the full suite of tests to get to the area where it has the issues.  I can't reproduce the problem if run those trouble areas standalone.

Jim

[Martin_fr]

10 Frames is the default limit shown. You can try to get more than 10 frames (drop  down or plus), but given that #10 is "at 0", there are likely no more.

Unfortunately Mac isn't my area of expertise. Not sure how best to find it.

A simple try/except is unlikely to do much good. Even if it stops your app from quitting, data would have been lost, and a SigAbrt is an error that shouldn't happen, so usually not recoverable (meaning, your tcp ip connection may be (even more) unstable after that).

[JimKueneman]

Found it!  I was passing the wrong object to free... man I have been using Lazarus on OSX for a LONG LONG time and have never seen this sort of mistake take OSX down so deep..... Though it was in a thread which may have been a factor (and clue based on other stack dumps when it crashed... they were mostly the same as what I posted but I finally caught one that has something that clued me into it was a thread crashing.

Thanks,
Jim

[Martin_fr]

Well for that sort of thing (dangling pointer) if you have a Linux VM (assuming your app could be compiled for Linux too), then just run your app through "valgrind --tool=memcheck".

[JimKueneman]

Actually there was 2 things going on in the same place... this one one problem then right after that I am trying to access a control to update it string directly from this worker thread... OSX does not like that at all... now some other stack hints make sense....  Just wasn't thinking when I did that.... (I had in mind that all that function did was place the data in a TThreadList but I forgot I added event handlers and such since it "normally" is only used from the main thread)

Jim

[JimKueneman]

That caught it. It’s been hammering on my stress test for the last 30 minutes without a problem before they couldn’t make it through once most of the time which took less than 30 seconds.