Post reply

Name:
Email:
Subject:
Message icon:
Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What is the last letter in the word "SlickEdit":
How many LETTERS are in the following? "a1b2c3":
Which number is missing?  "12345689":

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: Clark
« on: August 26, 2025, 04:09:47 PM »

Single file project break points don't seem to restore on macOS. You can reproduce this without exiting SlickEdit. Just switch files so the break points temporarily disappear. I built clang on Linux and this works fine. Not sure what's different on macOS. We will look into this.
Posted by: rjpontefract
« on: August 25, 2025, 07:44:15 PM »

Hi Clark,  can you test it with a single file C++ source without a project open? 
Posted by: Clark
« on: August 25, 2025, 01:34:40 PM »

When I restart, my breakpoints still work. I tested with the clang sample first and then on the SlickEdit source code. I've seen confusion if I make edits and rebuild (especially with gdb).
Posted by: rjpontefract
« on: August 24, 2025, 09:13:48 PM »

Hi Clark, thanks for the workaround, that seems to work.  Apple do seem intent on making things harder than they should be.
While you're taking a look at this can you see why breakpoints that are restored when SE is opened don't work while newly added ones do?
Cheers
Posted by: Clark
« on: August 24, 2025, 04:00:48 PM »

Quote from: rjpontefract on August 23, 2025, 01:42:45 AM
Did something break in macOS 15.6.1 and clang 17.0.0?

Using a single file project with no workspace open, I build a debug executable with the -fdebug-default-version=4 option included from a simple C++ source file.
Debugging use SE 29.0.3.0 starts, seems to stop on a breakpoint, but no debug symbols or line number info is available.  The only thread is T00001 and the stack frames are  _dyld_start()  and <unknown>, <unknown>.  No autos or locals are visible.

Debugging the resulting executable using LLDB from the CLI works as expected.

Any help would be appreciated.
 

This is not dependent on the version of clang. It's dependent on the version of macOS. Not sure of the exact cut off. Either >=15.5 or >=15.4 (not sure if 15.4 has this problem). It doesn't matter whether you rebuild your binary. This issue depends on the version of your macOS. <=15.3 doesn't have a problem for sure.

Here's a work around:

* Set a break point (maybe two). On my M1 I only had to set one break point. On my Intel mac mini, I had to set two break points. The first one doesn't work but needs to be there so the second one works.
* Start the debugger. Debug>Start. I haven't yet found a way to get Step Into to work.
* The debugger will stop on the weird _dyld_start() function. Run Debug>Continue (or hit the Play button on the debug tool bar). Now you should be on the first (or second break point).

We will be looking into this to see if we can come up with something better.
Posted by: rjpontefract
« on: August 23, 2025, 01:42:45 AM »

Did something break in macOS 15.6.1 and clang 17.0.0?

Using a single file project with no workspace open, I build a debug executable with the -fdebug-default-version=4 option included from a simple C++ source file.
Debugging use SE 29.0.3.0 starts, seems to stop on a breakpoint, but no debug symbols or line number info is available.  The only thread is T00001 and the stack frames are  _dyld_start()  and <unknown>, <unknown>.  No autos or locals are visible.

Debugging the resulting executable using LLDB from the CLI works as expected.

Any help would be appreciated.
 
Posted by: rjpontefract
« on: February 24, 2025, 01:31:40 AM »

There seems to be an issue on macOS where existing breakpoints don't work when a file is restored after restarting SE.  If I remove and re-add a breakpoint it works as expected.
Posted by: Clark
« on: February 07, 2025, 08:02:54 PM »

glad this works for you.

v30 there will have support for CMake's new file API. It's really good. Much better and more convenient that the old cmake support. Although you will have to manually change the compiler options if you want to be able to debug on macOS. No way to automate that.
Posted by: PaulElliott
« on: February 07, 2025, 04:26:57 PM »

This was with the clang workspace, my other projects are too complex for simple tests / built externally.

This was extremely curious. It didn't work until I started messing around with dsymutil on clang_prog, trying to ascertain what debug version it was using. At some point during this, breakpoints started catching again. I have since tried to break this by removing the files that this produces, but to no avail. For now, I will just take the win I think.

I will report back if I can find anything more on this, given many of my projects are being built externally with cmake, this is still something of an issue which won't get resolved with the hotfix either.
Posted by: Clark
« on: February 07, 2025, 01:48:26 AM »

Have you tried debugging with the clang sample?

Project>All Workspaces>Sample Workspaces>clang.vpw
Posted by: PaulElliott
« on: February 07, 2025, 12:01:53 AM »

Yep, definitely building debug, like I say, I can see the option on the build command line.

Only major difference then is I am running 15.2, but its still Apple clang version 16.0.0 (clang-1600.0.26.6) - I'm not entirely sure there was an upgrade.

Looks like I need to do some elf Mach-O analysis in the morning. Any hints and tips on this would be greatly appreciated, I know my way around an elf file, but but new on Mach-O.
Posted by: Clark
« on: February 06, 2025, 11:25:01 PM »

Upgrading to v29 shouldn't be required. The only change in v29 is automation for adding the extra compile option.

Make sure you build the Debug config and not Release. Build>Set Active Configuration

Debug won't work in a Release config

Posted by: PaulElliott
« on: February 06, 2025, 12:43:10 PM »

Quote from: Clark on February 05, 2025, 05:58:28 PM
Make sure you clear out the following setting:
Tools>Options>Debugging>General>Debug Server executable
Restart SlickEdit before trying to debug.

Hi Clark, definitely done that, I wasn't even able to start debugging until that was done, and that definitely fixes that, many thanks with your help catching that.

Now when I start debugging, the executable just runs straight through and no breakpoints catch. I have followed the instructions above on the clang project, checked that -fdebug-default-version=4 is definitely included on the build command line, however no breakpoints set in the editor are caught, the same symptoms as described in the initial post.

The only major difference here is that I am running v28 (hence no hot fix, so using the manual instructions). My question therefore, is whether or not this fix is expected to work in v28 with apple clang 16, or whether upgrading to v29 is required here.
Posted by: Clark
« on: February 05, 2025, 05:58:28 PM »

Quote from: PaulElliott on February 05, 2025, 05:30:14 PM
Hi all,
The above manual instructions do not seem to work for me (debug breakpoints still don't catch) on v28. Is this to be expected, and we have to upgrade to v29 to fix?
Make sure you clear out the following setting:

Tools>Options>Debugging>General>Debug Server executable

Restart SlickEdit before trying to debug.
Posted by: PaulElliott
« on: February 05, 2025, 05:30:14 PM »

Hi all,
The above manual instructions do not seem to work for me (debug breakpoints still don't catch) on v28. Is this to be expected, and we have to upgrade to v29 to fix?