Recent

Author Topic: Debugger stopped with reason: EXC_BAD_ACCESS  (Read 849 times)

AlexTP

  • Hero Member
  • *****
  • Posts: 2401
    • UVviewsoft
Debugger stopped with reason: EXC_BAD_ACCESS
« on: August 30, 2022, 06:27:55 pm »
Hi Martin, what do you think about this crash?
MacOS, x64 CudaText was running from the IDE (2.2.3 almost latest, maybe pulled 1-2 month ago, FPC 'fixes' branch).
https://github.com/Alexey-T/CudaText/issues/4322

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9857
  • Debugger - SynEdit - and more
    • wiki
Re: Debugger stopped with reason: EXC_BAD_ACCESS
« Reply #1 on: August 30, 2022, 08:31:13 pm »
Replied on the issue.

If it is (as I believe) a dangling object pointer, then you may want to try valgrind (easiest way to find where they happen).

Of course that means testing on Linux. But even if it does not crash on Linux, the error could still be there, and then valgrind would see it.

If not, and if the error only happens on Mac, it may be much harder to find.
Though you may want to enquire with the fpc team. I read recently that they added support for using llvm as backend, and through that enable valgrind like build in error checks (like -CRriot - just way better).

AlexTP

  • Hero Member
  • *****
  • Posts: 2401
    • UVviewsoft
Re: Debugger stopped with reason: EXC_BAD_ACCESS
« Reply #2 on: August 30, 2022, 08:36:00 pm »
I dont think it's a dangling pointer - user just works w/o closing editor-tabs, he just focuses the editor...

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9857
  • Debugger - SynEdit - and more
    • wiki
Re: Debugger stopped with reason: EXC_BAD_ACCESS
« Reply #3 on: August 30, 2022, 08:51:43 pm »
Well the message is displayed by the IDE, to show something that LLDB has printed.

There is an issues that the IDE was not able to parse the LLDB output. But that just explains the (badly) chosen wording of the message.

The output of LLDB happens first, so if the IDE parsed it, the IDE would write "the app stopped with error" instead of "the debugger ..."
Fixes in the IDE that are needed (need the "debug output":
- better wording
- better parsing

But those don't make the problem go away. The error happened before that.

And since you get a stack-trace, lldb is still alive.
Therefore the crash is in the debugged app.

As to what causes the crash =>  I don't know. I gave you my best guess, but there are a dozen other good causes that can crash an app.

And if it works outside the debugger:
- most likely:  a timing issues, since an attached debugger affects timing.
- less likely:  a bug in lldb

Least likely: There is an issue in how fpc writes line info. This issues can cause a debugger to set breakpoints incorrectly. So far the only manifestation known of this, is with gdb. But it could happen with lldb. If that is the case, do not use breakpoints:
- in the procedure in which the error occurred
- in the procedure immediately above (in source code order), skipping any procedures that are not called (those will not have blue dots)

If the error is caused by such a breakpoint, there is a bug report against fpc for that....

 

 

TinyPortal © 2005-2018