Breakpoints are not working in 2018r1, release, in from the Mac IDE. This is a critically serious issue (already added to an existing feedback case that mentioned this 7 hours ago for the Windows IDE) and I can’t come up with any workaround. Closing/reopening projects, trying again, etc: no luck.
We need a fix for this ASAP and/or at least re-post one of the previous final candidates to work with in the meantime. Dead in the water with this and shockingly and unpleasantly unexpected.
Got the same problem on Windows
I do not see this here, breakpoints seem to work for me with 2018r1.
EDIT: macOS High Sierra 10.13.4
[quote=383516:@Dana Gregory]Breakpoints are not working in 2018r1, release, in from the Mac IDE. This is a critically serious issue (already added to an existing feedback case that mentioned this 7 hours ago for the Windows IDE) and I can’t come up with any workaround. Closing/reopening projects, trying again, etc: no luck.
We need a fix for this ASAP and/or at least re-post one of the previous final candidates to work with in the meantime. Dead in the water with this and shockingly and unpleasantly unexpected.[/quote]
Literally debugging a project in 2018r1 on the Mac at the moment, setting breakpoints and stepping through. Seems fine, what am I missing?
If you start a new project in 2018r1 and set a breakpoint on a simple piece of code, it doesn’t hit the breakpoint and drop into the debugger at all?
Well, when I build debug in 64 bits everything works fine. Since it is too slow, I tried to go back to 32 bits. Then it doesn’t stop.
I’m running a 32-bit project. So it sounds like the issue is the MacOS IDE when working with 32-bit applications.
Looks like 32 Bits problem here too.
I am running a 64bit App on macOS (latest). If i set Breakpoints before i start the Debugger, they work. If i set BreakPoints after i’ve paused the Debugger and then continue, they do not work.
That worked for me :
I switched my project to 32 bits and then saved it as a new project.
Then it started to stop again on breakpoints.
That should not be necessary and my CVS will suffer from this.
Maybe just save it as a new project. Since I guess your project was created under the previous version, it might need to be saved under the new version, not just updated… Just a guess… I don’t really know if it might help or not.
I replaced the files (and kept my git folder intact) in my CVS and made a new commit.
Is the code in a class in a module? Because that’s the behavior I’ve reported in those cases. See
<https://xojo.com/issue/51832>
Otherwise, I can confirm the 32-bit behavior.
Unfortunately i can’t say right now. I “just” stopped using Breakpoints and started the guessing game (no time for additional logging…) 
The bug is specific to 32-bit debugging where the compiler was able to reuse a compiled version from the incremental compilation cache and that compiled version was generated from previous editing session (i.e. run, close the project, reopen the project).
On Windows 10, debugging Windows 10 32-bit apps. Debugger will sometimes stop, but it shows no method or variables. Other times it doesn’t even bother to stop. Unhandled Exception breaks always appear to show this behavior in my testing.
This is very likely the same issue. If you edit the code item where the debugger should break into and run, I would bet that it shows the correct method.
It’s clear the we all need a 2018R1.1 asap.
It’s in the works.
Are people thinking this is 32 bit only? I’m definitely seeing something amiss in 64 bit mac builds now as well.
I saw it this morning in my 64bit Linux web project.