Vscode-cpptools: [OSX 10.14.1] exec-run does not return confirmation, hangs debugging

[jeffreyqdd]

Type: Debugger

• OS and Version: macOS Mojave
• VS Code Version: 1.29.1
• C/C++ Extension Version: 0.20.1
• Other extensions you installed (and if the issue persists after disabling them): NONE
• A clear and concise description of what the bug is.
  I have two mac laptops with same OS and Visual code installation. Project setup are identical too. Debugger works well in laptop 2 but not laptop 1. The problematic one hangs after I started the debug (F5), only the "pause" button in the toolbar is highlighted. The log (trace=true) shows it stopped right before it started to load libraries.

To Reproduce
Code same here https://github.com/jeffreyqdd/usaco-train/tree/master/beads
it also contains launch.json and task.json.

Additional context

* logs
Log files from the macOS (laptop 1) with the issue:
<-- C (setFunctionBreakpoints-4): {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4}
<-- C (setExceptionBreakpoints-5): {"command":"setExceptionBreakpoints","arguments":{"filters":[]},"type":"request","seq":5}
<-- C (configurationDone-6): {"command":"configurationDone","type":"request","seq":6}
<-- C (threads-7): {"command":"threads","type":"request","seq":7}
Warning: Debuggee TargetArchitecture not detected, assuming x86_64.

Now this is the log file extracted from the MacOS (Laptop 2) runs the debugger correctly:
<-- C (setBreakpoints-3): {"command":"setBreakpoints","arguments":{"source":{"name":"beads.cpp","path":"/Users/eric/Projects/usaco-train/beads/beads.cpp"},"lines":[25],"breakpoints":[{"line":25}],"sourceModified":false},"type":"request","seq":3}
<-- C (setFunctionBreakpoints-4): {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4}
<-- C (setExceptionBreakpoints-5): {"command":"setExceptionBreakpoints","arguments":{"filters":[]},"type":"request","seq":5}
<-- C (configurationDone-6): {"command":"configurationDone","type":"request","seq":6}
<-- C (threads-7): {"command":"threads","type":"request","seq":7}
Warning: Debuggee TargetArchitecture not detected, assuming x86_64.
=thread-selected,id="1"
Loaded '/usr/lib/dyld'. Symbols loaded.
Loaded '/usr/lib/libc++.1.dylib'. Symbols loaded.
<....omitted more libary loading ...>
Loaded '/usr/lib/libobjc.A.dylib'. Symbols loaded.
Loaded '/Users/eric/Projects/usaco-train/beads/beads'. Symbols loaded.
<-- C (threads-8): {"command":"threads","type":"request","seq":8}
Execute debugger commands using "-exec ", for example "-exec info registers" will list registers in use (when GDB is the debugger)
<-- C (threads-9): {"command":"threads","type":"request","seq":9}
<-- C (stackTrace-10): {"command":"stackTrace","arguments":{"threadId":1,"startFrame":0,"levels":20},"type":"request","seq":10}
<-- C (stackTrace-11): {"command":"stackTrace","arguments":{"threadId":1,"startFrame":0,"levels":20},"type":"request","seq":11}
<-- C (scopes-12): {"command":"scopes","arguments":{"frameId":1004},"type":"request","seq":12}
<-- C (variables-13): {"command":"variables","arguments":{"variablesReference":1000},"type":"request","seq":13}
<-- C (evaluate-14): {"command":"evaluate","arguments":{"expression":"beads","frameId":1004,"context":"hover"},"type":"request","seq":14}
<-- C (variables-15): {"command":"variables","arguments":{"variablesReference":1005},"type":"request","seq":15}

* I have tried the following:
reinstall the vs code, wipe off extension folder, and reinstall the c/c++ extension. Still no luck

[pieandcakes]

@jeffreyqdd can you try and include "engineLogging": true also? I'm interested in seeing which command to lldb is causing it to freeze. Trace only shows messages from VS Code to our debug adapter.

[jeffreyqdd]

@pieandcakes thanks for quick reply. I enabled the log switch for both laptops. let me know if you need anything else.

see attachment - laptop1.eng.log (with the problem) and laptop2.eng.log(no issue)
laptop1.eng.log
laptop2.eng.log

[pieandcakes]

It looks like when we are sending 1: (824) <-1009-exec-run and in the problem case, we don't get 1: (1774) ->1009^running which is what we are waiting for.

I do see that the non-working version is running this version:

1: (1460) ->OS Version: 10.14.1 (18B75)
1: (1461) ->    Kernel: Darwin Kernel Version 18.2.0: Fri Oct  5 19:41:49 PDT 2018; root:xnu-4903.221.2~2/RELEASE_X86_64

where the working version is slightly older:

1: (714) ->OS Version: 10.14 (18A391)
1: (714) ->    Kernel: Darwin Kernel Version 18.0.0: Wed Aug 22 20:13:40 PDT 2018; root:xnu-4903.201.2~1/RELEASE_X86_64

[WardenGnaw]

I just investigated this issue. On the -exec-run, the Developer Tools Access is prompting for access. You may need to click on the terminal that pop's up when you start debugging so see the dialog.

Once you enter in your Username and Password, the debug session should continue. Or if it takes too long, it may die, but the subsequent debug sessions should work.

[jeffreyqdd]

The issue is that the asking for permission window never showed up. I thought it's something to do with the OS upgrade etc. So I have to reinstall the Xcode related tools (clang tool). Since I have other disk fragmentation issues anyway, I reinstalled the MacBook. now everything works. The Xcode Clang tool kicks in asking for permission control. after permission is given, everything works. Thanks for the investigation.

[userr2232]

I solved this by resetting all permissions from all Apps. I don't know if there is a command to reset the permissions related to the terminal only. I used this command:
tccutil reset All
Then I got the popup asking for permission and clicked Ok and everything worked fine again.