Date   

Re: Xcode won't compile sources

Quincey Morris
 

On Nov 19, 2017, at 18:28 , John Brownie <john_brownie@...> wrote:

Any pointers?

Also, check what scheme and device is currently selected (also the target, if it’s multi-target project), and make sure that the scheme is not corrupted (builds the correct target, for example).

Also, look in the build transcript to follow through the steps of what it does and what it doesn’t do.



Re: Xcode won't compile sources

Peter Teeson
 

I assume you did a clean? What does the log file say?
Does your backup version before you added the Swift files still compile?
Can you compile a file using the Product/Perform Action/Compile of a files selected in the navigator?
Can you do that for one of the newly added Swift files?

respect

Peter
P.S. Ukelele is a godsend… <grin>

On Nov 19, 2017, at 9:28 PM, John Brownie <john_brownie@sil.org> wrote:

With a working application written in a mixture of Obj-C, Obj-C++ and straight C++, I added some Swift files. After a bit of mucking around due to some header path issues, I have come to the point where it won't build, because it doesn't compile the sources. As far as I can tell, the sources are listed in the Compile Sources phase, but it gets skipped, and the linker complains that it can't find the files.

This is Xcode 8.3.2, on macOS 10.12.6. I've restarted the computer, cleaned the Build Folder, and tried what can think of, but this has me stumped.

Any pointers?

John
--
John Brownie
SIL-PNG, Ukarumpa, Eastern Highlands, Papua New Guinea
Mussau-Emira language, New Ireland Province, Papua New Guinea

-=-=-=-=-=-=-=-=-=-=-=-


Xcode won't compile sources

John Brownie
 

With a working application written in a mixture of Obj-C, Obj-C++ and straight C++, I added some Swift files. After a bit of mucking around due to some header path issues, I have come to the point where it won't build, because it doesn't compile the sources. As far as I can tell, the sources are listed in the Compile Sources phase, but it gets skipped, and the linker complains that it can't find the files.

This is Xcode 8.3.2, on macOS 10.12.6. I've restarted the computer, cleaned the Build Folder, and tried what can think of, but this has me stumped.

Any pointers?

John
--
John Brownie
SIL-PNG, Ukarumpa, Eastern Highlands, Papua New Guinea
Mussau-Emira language, New Ireland Province, Papua New Guinea


Re: Debugging Privileged Helper Tool

Mark Allan
 

In case anyone's interested, I resolved the issue a couple of days ago (I've been testing ever since, just to make sure.)

Instead of trying to debug the privileged helper tool (which appears to be all-but impossible), I attacked the problem from a different angle. I copied the class responsible into my main app and called it directly from there. After a few minutes in the debugger, I spotted the problem and fixed it.

FWIW, the root cause of the crash wasn't over-aggressive optimisation by the compiler, it was premature optimisation caused by me. I have a string variable whose value changes rapidly during app execution, so I thought I could save a few processor cycles by directly accessing the iVar instead of using the objective-c accessors. In hindsight, of course that's going to blow up at some point!

Changing the value to a property (atomic, strong) and using the appropriate accessors resolved the issue. It may be marginally less efficient, but it doesn't crash, so I'm happy with that for now.

Thanks for all the suggestions.
Mark

On 11 Nov 2017, at 10:02 pm, Mark Allan <markjallan@gmail.com> wrote:

Yeah given the mention of malloc in the stack trace, I thought that too, but memory usage in the helper stays constant at around 2.5MB. This is also the only crashlog that mentions malloc. The rest are all some variation on objects being over-released or released prematurely.

Application Specific Information:
objc_msgSend() selector name: isKindOfClass:

Thread 1 Crashed:: Dispatch queue: com.apple.root.default-qos
0 libobjc.A.dylib 0x00007fff5763ee9d objc_msgSend + 29
1 com.apple.Foundation 0x00007fff32d9f22d -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 2130
2 com.apple.Foundation 0x00007fff32d9e7e9 -[NSXPCConnection _sendSelector:withProxy:arg1:arg2:] + 125
3 com.apple.Foundation 0x00007fff32dad997 _NSXPCDistantObjectSimpleMessageSend2 + 46


On 10 Nov 2017, at 9:49 pm, Jack Brindle <jackbrindle@me.com> wrote:

That doesn’t look like an optimization issue, more like a lack of memory when the library goes to allocate memory for a new object.
XPC just seems to be triggering the object allocation. Is that side memory-limited or have some other constraints? Or is there a
leak causing it to run out of memory?

Debugging problem in code run by root (usually daemons) is much harder since Apple stopped us from logging in as root…
I’d bet there is a way to override that, though.

- Jack


On Nov 10, 2017, at 6:23 AM, Mark Allan <markjallan@gmail.com> wrote:

Hmm. I spoke too soon.

Even with -O3 and -O2, it still crashes. The backtrace shows the same line of my own code, but a different location within the macOS code.

Thread 2 Crashed:: Dispatch queue: com.apple.root.default-qos
0 libsystem_malloc.dylib 0x00007fff583e5318 tiny_malloc_from_free_list + 323
1 libsystem_malloc.dylib 0x00007fff583e4403 szone_malloc_should_clear + 422
2 libsystem_malloc.dylib 0x00007fff583e5cc0 malloc_zone_calloc + 87
3 libsystem_malloc.dylib 0x00007fff583e65d6 calloc + 30
4 libobjc.A.dylib 0x00007fff5763ecea class_createInstance + 87
5 libdispatch.dylib 0x00007fff58202baa _os_object_alloc_realized + 35
6 libxpc.dylib 0x00007fff584fab0d xpc_dictionary_create + 37
7 com.apple.Foundation 0x00007fff32d9ea82 -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 167
8 com.apple.Foundation 0x00007fff32d9e7e9 -[NSXPCConnection _sendSelector:withProxy:arg1:arg2:] + 125
9 com.apple.Foundation 0x00007fff32dad997 _NSXPCDistantObjectSimpleMessageSend2 + 46
10 com.myapp.mytool.HelperTool 0x00000001055b3ad7 -[HelperTool updateProgressWithMessage:forRun:] + 119 (HelperTool.m:501)
This happens after running for around an hour or so. I'm trying again now with "Fast [-O, O1]"...

Mark


Re: Missing man pages & docsets

tridiak
 

Thanks for help. xcode-select -p listed ‘/Library/Developer/CommandLineTools/‘ for some reason after I installed OS 10.13 & XC 9.

On 14/11/2017, at 8:45 AM, Jens Alfke <jens@mooseyard.com> wrote:



On Nov 10, 2017, at 6:02 PM, tridiak <tridiaknz@gmail.com> wrote:

Installed High Sierra & XC 9.
Tried to do ‘man fread’ and command line blabbed about no manual entry.
How do you install the missing man pages?
Run “xcode-select -p” and make sure the path to the Xcode app matches what it outputs. If not, use “sudo xcode-select -s” to set the right path. (You may have had a beta Xcode at a different path and had the tools set up to point to it…)

And WHERE does Apple store it’s XC 9 docsets (so Dash can import it)?
Again, Dash doesn’t have any trouble finding the docs on my system. Fixing the Xcode path above may fix this problem too.

Any idea how to “fix” the command-double click. It nows brings up a ctx menu instead of opening a new window.
Preferences > Navigation; change “Command-Click on Code” to “Jumps to definition”.

—Jens




Re: Missing man pages & docsets

 

On Nov 10, 2017, at 6:02 PM, tridiak <tridiaknz@gmail.com> wrote:

Installed High Sierra & XC 9.
Tried to do ‘man fread’ and command line blabbed about no manual entry.
How do you install the missing man pages?
Run “xcode-select -p” and make sure the path to the Xcode app matches what it outputs. If not, use “sudo xcode-select -s” to set the right path. (You may have had a beta Xcode at a different path and had the tools set up to point to it…)

And WHERE does Apple store it’s XC 9 docsets (so Dash can import it)?
Again, Dash doesn’t have any trouble finding the docs on my system. Fixing the Xcode path above may fix this problem too.

Any idea how to “fix” the command-double click. It nows brings up a ctx menu instead of opening a new window.
Preferences > Navigation; change “Command-Click on Code” to “Jumps to definition”.

—Jens


Missing man pages & docsets

tridiak
 

Installed High Sierra & XC 9.
Tried to do ‘man fread’ and command line blabbed about no manual entry.
How do you install the missing man pages?
And WHERE does Apple store it’s XC 9 docsets (so Dash can import it)?

Any idea how to “fix” the command-double click. It nows brings up a ctx menu instead of opening a new window.

Bloody Apple is so !@#@!# frustrating.
Somehow Apple manages to dumb things down AND complicate things at the same time.

Mark


Re: Debugging Privileged Helper Tool

Mark Allan
 

Yeah given the mention of malloc in the stack trace, I thought that too, but memory usage in the helper stays constant at around 2.5MB. This is also the only crashlog that mentions malloc. The rest are all some variation on objects being over-released or released prematurely.

Application Specific Information:
objc_msgSend() selector name: isKindOfClass:

Thread 1 Crashed:: Dispatch queue: com.apple.root.default-qos
0 libobjc.A.dylib 0x00007fff5763ee9d objc_msgSend + 29
1 com.apple.Foundation 0x00007fff32d9f22d -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 2130
2 com.apple.Foundation 0x00007fff32d9e7e9 -[NSXPCConnection _sendSelector:withProxy:arg1:arg2:] + 125
3 com.apple.Foundation 0x00007fff32dad997 _NSXPCDistantObjectSimpleMessageSend2 + 46

On 10 Nov 2017, at 9:49 pm, Jack Brindle <jackbrindle@me.com> wrote:

That doesn’t look like an optimization issue, more like a lack of memory when the library goes to allocate memory for a new object.
XPC just seems to be triggering the object allocation. Is that side memory-limited or have some other constraints? Or is there a
leak causing it to run out of memory?

Debugging problem in code run by root (usually daemons) is much harder since Apple stopped us from logging in as root…
I’d bet there is a way to override that, though.

- Jack


On Nov 10, 2017, at 6:23 AM, Mark Allan <markjallan@gmail.com> wrote:

Hmm. I spoke too soon.

Even with -O3 and -O2, it still crashes. The backtrace shows the same line of my own code, but a different location within the macOS code.

Thread 2 Crashed:: Dispatch queue: com.apple.root.default-qos
0 libsystem_malloc.dylib 0x00007fff583e5318 tiny_malloc_from_free_list + 323
1 libsystem_malloc.dylib 0x00007fff583e4403 szone_malloc_should_clear + 422
2 libsystem_malloc.dylib 0x00007fff583e5cc0 malloc_zone_calloc + 87
3 libsystem_malloc.dylib 0x00007fff583e65d6 calloc + 30
4 libobjc.A.dylib 0x00007fff5763ecea class_createInstance + 87
5 libdispatch.dylib 0x00007fff58202baa _os_object_alloc_realized + 35
6 libxpc.dylib 0x00007fff584fab0d xpc_dictionary_create + 37
7 com.apple.Foundation 0x00007fff32d9ea82 -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 167
8 com.apple.Foundation 0x00007fff32d9e7e9 -[NSXPCConnection _sendSelector:withProxy:arg1:arg2:] + 125
9 com.apple.Foundation 0x00007fff32dad997 _NSXPCDistantObjectSimpleMessageSend2 + 46
10 com.myapp.mytool.HelperTool 0x00000001055b3ad7 -[HelperTool updateProgressWithMessage:forRun:] + 119 (HelperTool.m:501)
This happens after running for around an hour or so. I'm trying again now with "Fast [-O, O1]"...

Mark


Re: Debugging Privileged Helper Tool

Bernie Maier
 

Jack Brindle:

Debugging problem in code run by root (usually daemons) is much harder since
Apple stopped us from logging in as root… I’d bet there is a way to
override that, though.
I could be way off the mark here because I don't recall ever attempting to debug a daemon on macOS. But just in case you aren't aware of the standard old Unix technique, can you not somehow leverage off a simple:

$ sudo su -
Password: <your password, assuming you are in a shell as an admin user>
root#


- Jack


On Nov 10, 2017, at 6:23 AM, Mark Allan <markjallan@gmail.com> wrote:

Hmm. I spoke too soon.

Even with -O3 and -O2, it still crashes. The backtrace shows the same
line of my own code, but a different location within the macOS code.

Thread 2 Crashed:: Dispatch queue: com.apple.root.default-qos
0 libsystem_malloc.dylib 0x00007fff583e5318
tiny_malloc_from_free_list + 323 1 libsystem_malloc.dylib
0x00007fff583e4403 szone_malloc_should_clear + 422 2
libsystem_malloc.dylib 0x00007fff583e5cc0 malloc_zone_calloc + 87
3 libsystem_malloc.dylib 0x00007fff583e65d6 calloc + 30 4
libobjc.A.dylib 0x00007fff5763ecea class_createInstance +
87 5 libdispatch.dylib 0x00007fff58202baa
_os_object_alloc_realized + 35 6 libxpc.dylib
0x00007fff584fab0d xpc_dictionary_create + 37 7 com.apple.Foundation
0x00007fff32d9ea82 -[NSXPCConnection
_sendInvocation:orArguments:count:methodSignature:selector:withProxy:] +
167 8 com.apple.Foundation 0x00007fff32d9e7e9
-[NSXPCConnection _sendSelector:withProxy:arg1:arg2:] + 125 9
com.apple.Foundation 0x00007fff32dad997
_NSXPCDistantObjectSimpleMessageSend2 + 46 10
com.myapp.mytool.HelperTool 0x00000001055b3ad7 -[HelperTool
updateProgressWithMessage:forRun:] + 119 (HelperTool.m:501)
This happens after running for around an hour or so. I'm trying again now
with "Fast [-O, O1]"...

Mark

On 10 Nov 2017, at 10:33 am, Mark Allan <markjallan@gmail.com> wrote:

Hi Alex,

It takes a while to reproduce the issue, so I'm still running tests, but
yes changing the optimisation setting to Fastest [-O3] *appears* to fix
the issue. I was assuming the issue was with my own code, so I didn't
want to rely on changing optimisation settings, but the more I scrutinise
and test, the more I'm coming to believe it is over-aggressive
optimisation. Thank you.

Mark

On 9 Nov 2017, at 5:23 pm, Alex Zavatone <zav@mac.com> wrote:

Mark, would this be as simple as changing the optimization settings for
your release mode not to be "Fastest Smallest [-Os]”?

I seem to remember running into something similar to this type of crash
using libs on iOS due to over aggressive optimization.

What I do remember for sure was that our iOS app using "Fastest Smallest
[-Os]” for external .a libs most certainly caused a similar crash when
run from Xcode in a Debug build configuration.

Does this run for you if you change the optimization settings in release?




Re: Debugging Privileged Helper Tool

Jack Brindle
 

That doesn’t look like an optimization issue, more like a lack of memory when the library goes to allocate memory for a new object.
XPC just seems to be triggering the object allocation. Is that side memory-limited or have some other constraints? Or is there a
leak causing it to run out of memory?

Debugging problem in code run by root (usually daemons) is much harder since Apple stopped us from logging in as root…
I’d bet there is a way to override that, though.

- Jack

On Nov 10, 2017, at 6:23 AM, Mark Allan <markjallan@gmail.com> wrote:

Hmm. I spoke too soon.

Even with -O3 and -O2, it still crashes. The backtrace shows the same line of my own code, but a different location within the macOS code.

Thread 2 Crashed:: Dispatch queue: com.apple.root.default-qos
0 libsystem_malloc.dylib 0x00007fff583e5318 tiny_malloc_from_free_list + 323
1 libsystem_malloc.dylib 0x00007fff583e4403 szone_malloc_should_clear + 422
2 libsystem_malloc.dylib 0x00007fff583e5cc0 malloc_zone_calloc + 87
3 libsystem_malloc.dylib 0x00007fff583e65d6 calloc + 30
4 libobjc.A.dylib 0x00007fff5763ecea class_createInstance + 87
5 libdispatch.dylib 0x00007fff58202baa _os_object_alloc_realized + 35
6 libxpc.dylib 0x00007fff584fab0d xpc_dictionary_create + 37
7 com.apple.Foundation 0x00007fff32d9ea82 -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 167
8 com.apple.Foundation 0x00007fff32d9e7e9 -[NSXPCConnection _sendSelector:withProxy:arg1:arg2:] + 125
9 com.apple.Foundation 0x00007fff32dad997 _NSXPCDistantObjectSimpleMessageSend2 + 46
10 com.myapp.mytool.HelperTool 0x00000001055b3ad7 -[HelperTool updateProgressWithMessage:forRun:] + 119 (HelperTool.m:501)
This happens after running for around an hour or so. I'm trying again now with "Fast [-O, O1]"...

Mark

On 10 Nov 2017, at 10:33 am, Mark Allan <markjallan@gmail.com> wrote:

Hi Alex,

It takes a while to reproduce the issue, so I'm still running tests, but yes changing the optimisation setting to Fastest [-O3] *appears* to fix the issue. I was assuming the issue was with my own code, so I didn't want to rely on changing optimisation settings, but the more I scrutinise and test, the more I'm coming to believe it is over-aggressive optimisation. Thank you.

Mark

On 9 Nov 2017, at 5:23 pm, Alex Zavatone <zav@mac.com> wrote:

Mark, would this be as simple as changing the optimization settings for your release mode not to be "Fastest Smallest [-Os]”?

I seem to remember running into something similar to this type of crash using libs on iOS due to over aggressive optimization.

What I do remember for sure was that our iOS app using "Fastest Smallest [-Os]” for external .a libs most certainly caused a similar crash when run from Xcode in a Debug build configuration.

Does this run for you if you change the optimization settings in release?



Re: Mac App Store: Screenshot resolutions

Jeremy Hughes
 

Hi Alex,

On 10 Nov 2017, at 20:13, Alex Zavatone <zav@mac.com> wrote:

Considering that this is an issue that we all must face, there are several tools that have been put together to automate this process - be it for iOS, Mac OS or tvOS.

Since we all have our own distribution needs, what solutions have you all found that already solve this problem and which do you prefer?
I used Grab and Pixelmator.

Jeremy


Re: Mac App Store: Screenshot resolutions

Alex Zavatone
 

Considering that this is an issue that we all must face, there are several tools that have been put together to automate this process - be it for iOS, Mac OS or tvOS.

Since we all have our own distribution needs, what solutions have you all found that already solve this problem and which do you prefer?

Thanks.
Alex Zavatone

On Nov 10, 2017, at 2:05 PM, Jeremy Hughes <moon.rabbit@virginmedia.com> wrote:

On 10 Nov 2017, at 18:34, Quincey Morris <quinceymorris@rivergatesoftware.com> wrote:

On Nov 10, 2017, at 09:42 , Jeremy Hughes <moon.rabbit@virginmedia.com> wrote:

it seems that the term “screenshot” is being used loosely to include any image that contains a screenshot
Exactly. You’re submitting an image of a standard size that typically contains a window image obtained by taking a screenshot. The window image size can be anything that fits within the larger image. The main thing to keep in mind is that scaling the window image up is undesirable. Scaling it down is more acceptable, but for best results choose a window size that doesn’t require any scaling to fit into the final image.

Also, make sure that you do this in terms of pixels, so that there’s no unintended scaling.
Thanks Quincey!

Jeremy




Re: Mac App Store: Screenshot resolutions

Jeremy Hughes
 

On 10 Nov 2017, at 18:34, Quincey Morris <quinceymorris@rivergatesoftware.com> wrote:

On Nov 10, 2017, at 09:42 , Jeremy Hughes <moon.rabbit@virginmedia.com> wrote:

it seems that the term “screenshot” is being used loosely to include any image that contains a screenshot
Exactly. You’re submitting an image of a standard size that typically contains a window image obtained by taking a screenshot. The window image size can be anything that fits within the larger image. The main thing to keep in mind is that scaling the window image up is undesirable. Scaling it down is more acceptable, but for best results choose a window size that doesn’t require any scaling to fit into the final image.

Also, make sure that you do this in terms of pixels, so that there’s no unintended scaling.
Thanks Quincey!

Jeremy


Re: Mac App Store: Screenshot resolutions

Quincey Morris
 

On Nov 10, 2017, at 09:42 , Jeremy Hughes <moon.rabbit@...> wrote:

it seems that the term “screenshot” is being used loosely to include any image that contains a screenshot

Exactly. You’re submitting an image of a standard size that typically contains a window image obtained by taking a screenshot. The window image size can be anything that fits within the larger image. The main thing to keep in mind is that scaling the window image up is undesirable. Scaling it down is more acceptable, but for best results choose a window size that doesn’t require any scaling to fit into the final image.

Also, make sure that you do this in terms of pixels, so that there’s no unintended scaling.


On Nov 10, 2017, at 09:45 , Alex Zavatone <zav@...> wrote:

The link you posted mentions iOS app submission requirements.

And, just a bit further down the page, macOS, tvOS and watchOS requirements.


Re: Mac App Store: Screenshot resolutions

Alex Zavatone
 


On Nov 10, 2017, at 10:06 AM, Jeremy Hughes <moon.rabbit@...> wrote:

On 10 Nov 2017, at 16:04, Alex Zavatone <zav@...> wrote:

For iOS apps?  You didn’t mention if it was for iOS or Mac OS.

I did say Mac App Store, so this is macOS.


The link you posted mentions iOS app submission requirements.


Screenshot specifications

You must provide a set of screenshots for all device types. For iPhone, you need one set of screenshots for 5.5-inch display, and for iPad, you need one set for 12.9-inch display.




Re: Mac App Store: Screenshot resolutions

Jeremy Hughes
 

On 10 Nov 2017, at 16:01, Jeremy Hughes <moon.rabbit@virginmedia.com> wrote:

The Mac App Store requires screenshots to be in one of a limited set of sizes: 1280 x 800, 1440 x 900, 2560 x 1600, and 2880 x 1800

http://help.apple.com/itunes-connect/developer/#/devd274dd925

None of these screen sizes is available on my Mac Mini (my screen is 1920 x 1080, and scaled options are 1600 x 900 or 1344 x 756).

I also tried a new (2017) 21.5 Retina iMac, but that doesn’t have these sizes, either.

Do I need to run a virtual OS to get these screen sizes, or is there an easier way? What do other people do?
I’ve looked at some of the applications in the Mac App Store, including Apple’s, and it seems that the term “screenshot” is being used loosely to include any image that contains a screenshot. So it seems like I could submit a 2560 x 1600 image that contains some text along with a 1920 x 1080 screenshot (for example).

Apple examples include Pages, Numbers, etc.

Jeremy


Re: Mac App Store: Screenshot resolutions

Jeremy Hughes
 

On 10 Nov 2017, at 16:04, Alex Zavatone <zav@mac.com> wrote:

For iOS apps? You didn’t mention if it was for iOS or Mac OS.
I did say Mac App Store, so this is macOS.

Jeremy


Re: Mac App Store: Screenshot resolutions

Alex Zavatone
 

For iOS apps? You didn’t mention if it was for iOS or Mac OS.

Save them out of the simulator. Use an app to resize them.

On Nov 10, 2017, at 10:01 AM, Jeremy Hughes <moon.rabbit@virginmedia.com> wrote:

Hi,

The Mac App Store requires screenshots to be in one of a limited set of sizes: 1280 x 800, 1440 x 900, 2560 x 1600, and 2880 x 1800

http://help.apple.com/itunes-connect/developer/#/devd274dd925

None of these screen sizes is available on my Mac Mini (my screen is 1920 x 1080, and scaled options are 1600 x 900 or 1344 x 756).

I also tried a new (2017) 21.5 Retina iMac, but that doesn’t have these sizes, either.

Do I need to run a virtual OS to get these screen sizes, or is there an easier way? What do other people do?

Jeremy




Mac App Store: Screenshot resolutions

Jeremy Hughes
 

Hi,

The Mac App Store requires screenshots to be in one of a limited set of sizes: 1280 x 800, 1440 x 900, 2560 x 1600, and 2880 x 1800

http://help.apple.com/itunes-connect/developer/#/devd274dd925

None of these screen sizes is available on my Mac Mini (my screen is 1920 x 1080, and scaled options are 1600 x 900 or 1344 x 756).

I also tried a new (2017) 21.5 Retina iMac, but that doesn’t have these sizes, either.

Do I need to run a virtual OS to get these screen sizes, or is there an easier way? What do other people do?

Jeremy


Re: Debugging Privileged Helper Tool

Alex Zavatone
 

On Nov 10, 2017, at 4:33 AM, Mark Allan <markjallan@gmail.com> wrote:

Hi Alex,

It takes a while to reproduce the issue, so I'm still running tests, but yes changing the optimisation setting to Fastest [-O3] *appears* to fix the issue. I was assuming the issue was with my own code, so I didn't want to rely on changing optimisation settings, but the more I scrutinise and test, the more I'm coming to believe it is over-aggressive optimisation. Thank you.

Mark

AHA! Now I remember why! The most aggressive optimization prevents the debugger from operating or accessing the object code it needs IIRC. Basically debugger access is optimized out. iI forget the details, but am quite happy that this addresses your issue.

1101 - 1120 of 1433