Remote Debug to High Sierra

Is anyone able to remote debug into a High Sierra installation?

I keep getting the message “Could not launch the file because No such directory ‘W.hdrtistnxstyle’ 0”

Even though the download location is “/Users/Rowlands/Documents”.

Remote Debugger 2.1 32-Bit

Okay; so today this is working with a simple application, but not my main application… More investigation required.

hmm… below is the console log. Any clues? A simple application works fine; but my actual project fails, seems like some kind of corruption as “hdrtistnxstyle” is a document type for the application.

[quote]Jun 24 11:01:25 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:25 AM: Connection established
Jun 24 11:01:25 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:25 AM: Stub<-IDE HELLO, 17.1.1a0, Protocol: 6, Local IP: 192.168.0.11
Jun 24 11:01:25 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:25 AM: Using protocol version 6
Jun 24 11:01:25 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:25 AM: IDE Version supported
Jun 24 11:01:25 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:25 AM: Stub->IDE OLLEH, 1.9.030, 6, Remote Address: 192.168.0.14
Jun 24 11:01:25 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:25 AM: Stub<-IDE PLATFORM-REQUEST
Jun 24 11:01:25 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:25 AM: Stub->IDE PLATFORM-RESPONSE, Macintosh, x86-64, Mach-O, 10.9.0
Jun 24 11:01:41 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:41 AM: Stub<-IDE CREATEFILE, HDRtist NX.debug.app.tar.gz, Relative path: True,
Jun 24 11:01:41 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:41 AM: Stub->IDE CHALLENGE, 123EBF 192.168.0.11 192.168.0.14
Jun 24 11:01:41 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:41 AM: Waiting for RESPONSE
Jun 24 11:01:41 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:41 AM: Got a RESPONSE packet, about to decrypt
Jun 24 11:01:41 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:41 AM: Stub<-IDE RESPONSE, 123EC0 192.168.0.14 192.168.0.11
Jun 24 11:01:41 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:41 AM: Response accepted
Jun 24 11:01:41 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:41 AM: Creating file: /Users/rowlands/Documents/HDRtist NX.debug.app.tar.gz
Jun 24 11:01:41 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:41 AM: Created the file list
Jun 24 11:01:41 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:41 AM: Added the file or folder to the file list
Jun 24 11:01:41 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:41 AM: Stub->IDE FILECREATION, File ID: 0, Status: 0
Jun 24 11:01:41 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:41 AM: Stub<-IDE FILEINFO, File ID: 0, Size: 1.453325e+7, Compressed: False, Stub Delete: False
Jun 24 11:01:43 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:43 AM: Stub<-IDE FILEPART, File ID: 0
Jun 24 11:01:45 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:45 AM: Stub<-IDE FILEPART, File ID: 0
Jun 24 11:01:47 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:47 AM: Stub<-IDE FILEPART, File ID: 0
Jun 24 11:01:48 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:48 AM: Stub<-IDE FILEPART, File ID: 0
Jun 24 11:01:50 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:50 AM: Stub<-IDE FILEPART, File ID: 0
Jun 24 11:01:52 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:52 AM: Stub<-IDE FILEPART, File ID: 0
Jun 24 11:01:54 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:54 AM: Stub<-IDE FILEPART, File ID: 0
Jun 24 11:01:56 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:56 AM: Stub<-IDE FILEPART, File ID: 0
Jun 24 11:01:58 Sams-MacBook Remote Debugger Desktop[2613]: 11:01:58 AM: Stub<-IDE FILEPART, File ID: 0
Jun 24 11:02:00 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:00 AM: Stub<-IDE FILEPART, File ID: 0
Jun 24 11:02:02 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:02 AM: Stub<-IDE FILEPART, File ID: 0
Jun 24 11:02:04 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:04 AM: Stub<-IDE FILEPART, File ID: 0
Jun 24 11:02:06 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:06 AM: Stub<-IDE FILEPART, File ID: 0
Jun 24 11:02:07 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:07 AM: Stub<-IDE FILEPART, File ID: 0
Jun 24 11:02:07 — last message repeated 1 time —
Jun 24 11:02:07 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:07 AM: Stub->IDE FILEWRITTEN, File ID: 0, Status: 0
Jun 24 11:02:07 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:07 AM: Stub<-IDE FILELAUNCH, File ID: 0, Launch in Terminal: False, Command line args:
Jun 24 11:02:07 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:07 AM: Stub->IDE CHALLENGE, 123EC1 192.168.0.11 192.168.0.14
Jun 24 11:02:07 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:07 AM: Got a RESPONSE packet, about to decrypt
Jun 24 11:02:07 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:07 AM: Stub<-IDE RESPONSE, 123EC2 192.168.0.14 192.168.0.11
Jun 24 11:02:07 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:07 AM: Response accepted
Jun 24 11:02:07 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:07 AM: Decompressing HDRtist NX.debug.app.tar.gz
Jun 24 11:02:08 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:08 AM: Untarring HDRtist NX.debug.app.tar
Jun 24 11:02:09 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:09 AM: Could not launch HDRtist NX.debug.app.tar.gz No such directory ‘W.hdrtistnxstyle’
Jun 24 11:02:09 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:09 AM: Stub->IDE SOS, Could not launch the file because No such directory ‘W.hdrtistnxstyle’ 0
Jun 24 11:02:10 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:10 AM: Stub<-IDE SEEYA
Jun 24 11:02:10 Sams-MacBook Remote Debugger Desktop[2613]: 11:02:10 AM: Connection closed
[/quote]

What happens if you tell the stub not to launch automatically and then launch manually when it’s ready?

Does it work if you run the IDE on that OS?

Oh, and I probably don’t need to tell you, file a bug report which specifically calls out macOS 10.13 or High Sierra in the subject line. We’ll be looking at these later this summer as the OS nears completion.

I’ll try in the morning

It works; I don’t get any errors. Thanks Greg.

The IDE works fine, but my project uses a lot of shared components, so moving it across is a PITA.

Spoke to soon, realized that it was running an older version of the application and not the actual one I was debugging. Once I deleted the previous files and tried again, I now get this message flash for a second or two and then disappear.

You can unpack it and then start it and works fine ?

I think the question was more “if you put an ide and sources on this machine does that work to debug?”

Cant unpack … ???
I’ve never seen that one before
You dont have aliases, symlinks etc in the build when you run locally do you ?

Just trying to think of what else could cause that kind of error

OH and if you do set the stub to NOT launch on receipt what files do you get ?
Those would be instructive attached privately to the report if you can

I just re-opened the remote debugger and got a brand new error message, I’ll attached that to the report as well.

Updated the report with the debug files, console log and new error message. Seems like either I’ve got a borked installation of High Sierra, or APFS doesn’t like the Remote Debugger.

ah
The stub is being translocated … wonder what that does to it :slight_smile:

[quote=337853:@Norman Palardy]ah
The stub is being translocated … wonder what that does to it :)[/quote]
Nothing good it would seem!

Doesn’t seem to make it NOT run BUT I bet this causes grief trying to unpack things

What does removing the quarantine attribute do for this ?

Just to get some comparative data; I’ve just tried remote debugging to Yosemite and I’m getting the same problems. So it’s not a High Sierra issue. It’s an issue with my project.

Found and fixed the issue for the next round
I emailed you about whats up

[quote=337935:@Norman Palardy]Found and fixed the issue for the next round
I emailed you about whats up[/quote]
Oh Cool! Good work Norman, I’ll check it out when I get to my work machine.

JUST for those following along DONT USE FILES WITH / in their name forOS X and Linux
That turns out to be crucial to the issue Sam reported

Embarrassed that it’s all my fault. Sorry and thanks to the guys at Xojo for working hard to get to the bottom of this.

There was a file called “Strong B/W.hdrtistnxstyle” (yes the OS allowed it as a valid file name), which was causing problems.