search

albertziegenhagel / childdebugger-vscode

VS Code extension to auto-attach a debugger to child processes for `cppvsdbg`.
MIT License
4 stars 0 forks source link

Build Instructions #8

Open jasonwilliams opened 2 months ago

jasonwilliams commented 2 months ago

Hey @albertziegenhagel

Do you have instructions on how you've been building this extension? I would love to play with it but don't know what steps you took (sorry my C/C++ foo is rough)

Thanks

albertziegenhagel commented 2 months ago

I don't have detailed instructions on how to build the project from source yet, sorry. The best information I can provide at the moment is to have a look at the CI workflow in https://github.com/albertziegenhagel/childdebugger-concord/blob/main/.github/workflows/ci.yml.

On the other hand, there are pre-build binaries for x64 in the Github releases at https://github.com/albertziegenhagel/childdebugger-concord/releases/tag/head, which should hopefully work for you.

I've just added a very rough getting started guide for the complete project which can now be found here: https://github.com/albertziegenhagel/childdebugger-vscode.

And thanks a lot for the willingness to try it all out. There are a lot of known limitation that I yet need to document somewhere, but maybe it is of some value already. Feel free to comment on anything that doesn't work or any general ideas/suggestions. PRs are of course always welcome!

jasonwilliams commented 2 months ago

Hey, I've followed the build instructions, it doesn't seem to be connecting to new processes for some reason. in the debug console I do see:

-------------------------------------------------------------------
You may only use the C/C++ Extension for Visual Studio Code
with Visual Studio Code, Visual Studio or Visual Studio for Mac
software to help you develop and test your applications.
-------------------------------------------------------------------
Loading extensions from 'C:\dev\childdebugger-concord\bin'.

So it seems that bit is working. the breakpoint is red so looks like it is being set but it doesn't fire. Im testing this in Chromium, do you have any steps to reproducing what you're seeing? Should i be seeing anything else in the console?

Edit: It might be because im using attach and by the time it connects the relevant processes have been created, although I would expect this to work for new tabs

Edit 2: Ok it seems to fail to launch when I have the plugin enabled, ill print some logs: Debug Console

-------------------------------------------------------------------
You may only use the C/C++ Extension for Visual Studio Code
with Visual Studio Code, Visual Studio or Visual Studio for Mac
software to help you develop and test your applications.
-------------------------------------------------------------------
Loading extensions from 'C:\dev\childdebugger-concord\bin'.
Loaded 'C:\dev\chromium\src\out\Default\chrome.exe'. Symbols loaded.
The program '[22116] chrome.exe' has exited with code 0 (0x0).

ChildDebugger.log

Skip loading no-suspend executable names from non-existent file C:\dev\childdebugger-concord\bin\ChildDebugger-no_suspend.txt
OnProcessCreate (Debugger PID 34600)
  C:\dev\chromium\src\out\Default\chrome.exe
  PID 22116
  THREAD ID 5500 OWNER 22116
  CALL ResumeThread
  RESULT 1

I don't have anything in the ChildDebugger output channel

albertziegenhagel commented 2 months ago

Unfortunately, I was not yet able to reproduce the exact same issues that you are seeing when running chrome (I use a pre-build, installed version since I do not have a self-build chrome here). My launch.yml looks like this:

        {
            "name": "chrome",
            "type": "cppvsdbg",
            "request": "launch",
            "program": "C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
            "stopAtEntry": false,
            "console": "integratedTerminal",
        }

But the half backed suspend/resume logic (see albertziegenhagel/childdebugger-vscode#9) that I have build into the code might be the reason it is not working for you. Could you try to create the ChildDebugger-no_suspend.txt file that is mentioned in the in very beginning of the ChildDebugger.log (for you that should be C:\dev\childdebugger-concord\bin\ChildDebugger-no_suspend.txt) and just put a single line with

chrome.exe

in it. This should stop the extension from trying to suspend/resume any child processes while attaching the debugger.

For me it seems to work without that change, but it seems to attach to only two child processes of chrome, although I see 12 chome.exe processes in the Task Manager (with 4 tabs open). Do you know whether chrome launches all of it's child processes via CreateProcessA/CreateProcessW?

In the DEBUG CONSOLE, you should see lines like this:

ChildDebugger: attach to child NAME 'chrome.exe' PID 24416 TID 21076 SUSPENDED

and in the ChildDebugger output you should see

Attempting attach to child 24416

Other than that, you can try to use the test programs that are should have been build with these repositories. My launch.yml for this looks like this:

        {
            "name": "caller",
            "type": "cppvsdbg",
            "request": "launch",
            "program": "C:\\Users\\aziegenhagel\\build\\childdebugger-concord\\debug\\tests\\bin\\caller.exe",
            "args": [
                "C:\\Users\\aziegenhagel\\build\\childdebugger-concord\\debug\\tests\\bin\\callee.exe"
            ],
            "stopAtEntry": false,
            "console": "integratedTerminal"
        },

You would have to replace C:\\Users\\aziegenhagel\\build\\childdebugger-concord\\debug with wherever your build directory is located, and then you should see something like this

image

in the call stack view of VS Code.

jasonwilliams commented 1 month ago

Interestingly with integrated console I see it give me a different status code C:\dev\chromium\src\out\Default\chrome.exe (process 38020) exited with code -1073740972.

If I launch the same chrome.exe from powershell, it launches fine so I think its the debugger breaking it somehow. Also, If I remove the ChildDebugger.link file from C:\Users\[User]\.cppvsdbg\extensions it also launches fine from that launch config.

Here is the output from my ChildDebugger.log file

Loaded no-suspend executable names from C:\dev\childdebugger-concord\bin\ChildDebugger-no_suspend.txt:
  chrome.exe
OnProcessCreate (Debugger PID 27020)
  C:\dev\chromium\src\out\Default\chrome.exe
  PID 36916
OnModuleInstanceLoad (Debugger PID 27020)
  kernel32.dll
  Base address 140720737746944
  Function address CreateProcessW @118384
OnModuleInstanceLoad (Debugger PID 27020)
  kernel32.dll
  Base address 140720737746944
  Function address CreateProcessA @117360
OnRuntimeBreakpoint (Debugger PID 27020)
  In PID 36916: Start CreateProcess: W 1 Func 0
  APP C:\dev\chromium\src\out\Default\chrome.exe
  CL C:\dev\chromium\src\out\Default\chrome.exe --type=crashpad-handler "--user-data-dir=C:\Users\[User]\AppData\Local\Chromium\User Data" /prefetch:4 --monitor-self --monitor-self-argument=--type=crashpad-handler "--monitor-self-argument=--user-data-dir=C:\Users\[User]\AppData\Local\Chromium\User Data" --monitor-self-argument=/prefetch:4 --monitor-self-annotation=ptype=crashpad-handler "--database=C:\Users\[User]\AppData\Local\Chromium\User Data\Crashpad" --annotation=plat=Win64 --annotation=prod=Chromium --annotation=ver=128.0.6581.0-devel --initial-client-data=0x118,0x11c,0x120,0xf4,0x124,0x7ffb9a244ad0,0x7ffb9a244ae0,0x7ffb9a244aa0
  Originally requested suspended start
OnRuntimeBreakpoint (Debugger PID 27020)

Do you know whether chrome launches all of it's child processes via CreateProcessA/CreateProcessW?

I have no idea sadly.. How can i find out?

In the DEBUG CONSOLE, you should see lines like this: I don't see that in the debug console, im guessing its crashing out before getting that far. Im not sure what it is, but i've seen attach eventually crash. My assumption is the spawning of a new thread is killing it somewhere in this plugin.

I do see this in the child debugger output:

Attempting attach to child 23788
  attach: succeeded
Attempting attach to child 24940
  attach: succeeded

Other than that, you can try to use the test programs that are should have been build with these repositories. My launch.yml for this looks like this:

I would need to know how to build the example before trying it, ill have to give it a go at some point

albertziegenhagel commented 1 month ago

@jasonwilliams I've made some major changes to both the projects, which should (hopefully) make everything a lot more robust:

Additionally the binaries in the release package are now build in debug mode and include the *.pdb files. This should allow you to debug the extension without the need to build it from source. I would suggest that you add "stopAtEntry": true to your launch.json that starts chromium. Then, while the debugger is still paused at the entry point, you can attach another VS Code instance to the vsdbg.exe executable that is representing the debug session. Now, if there is an error in the debug engine extension, it should hopefully break the debugger. You might need to tell it where the source files are on your machine, since they will be in a different location that they where on the build machine.

Furthermore, I have added the test executables caller.exe and callee.exe to the release package. That should allow you to try the launch.json config that I posted above and see whether this works for you.

jasonwilliams commented 1 month ago

@albertziegenhagel you are a genius, it works! I can debug into Chromium and it doesn't seem to be having any problems at all (from my quick testing anyway). PS: Why is the extension size so much bigger than before? Previous release was 398KB, now its 2,322 KB (2.3MB)

Thank you so much for this, if only there was a way we could get this back into the upstream branches so developers didn't need an extension and an additional VS Code Plugin.

CC @gregg-miskelly @WardenGnaw

albertziegenhagel commented 1 month ago

it works!

I am very happy to hear that :) and thanks a lot for trying it out!

Previous release was 398KB, now its 2,322 KB (2.3MB)

The reason is that I am actually already packing the concord extension binaries with the VS code extension (totally forgot about this when I wrote the "getting started" guide...), and since I changed the binary from a release build to a debug build and additionally pack the PDB file, the size got much bigger. Eventually, I plan to pack a release build again and probably provide the PDB file as a separate download in the release assets.

I have some code for the VS code extension that will automatically install the *.link file into the $HOME/.cppvsdbg/extensions folder (and remove it again when the extension is uninstalled). Hopefully I will be able to finish and push the changes over the weekend. Then, we should be able to publish the extension in the VS Code Marketplace and people installing it would not need to do any additional, manual setup anymore.

jasonwilliams commented 1 month ago

I do have another C++ application where this doesn't seem to attach to child processes, i assume it might be using a different system call for spawning processes that this extension doesn't know about?

What's interesting is that it embeds Chromium and this extension attaches to Chromium code just fine, but not the processes above. (which is why i was thinking about different sys calls)

If i helps I do get this in the VS Code - ChildDebugger output a lot:

Sending child debugger settings failed: "CodeExpectedError: Error processing 'vsCustomMessage' request. A component dll failed to load. Try to restart this application. If failures continue, try disabling any installed add-ins or repair your installation."

Edit: I only see CreateProcessA and CreateProcessW so maybe its not an issue with unsupported system calls

albertziegenhagel commented 1 month ago

Sorry for the late answer. I am currently travelling, so time to work on this is very limited.

Those error messages you are getting are very likely to explain it. If VS Code starts a new debug session (no matter whether it's for a parent or child process) it first sends the settings that you might have set up in VS Code to the debugger extension. On the debug engine extension side, attaching to children is disabled by default and it will only be enabled when receiving that settings message.

So, since it seems that this message fails to be send, the child processing will probably never be enabled.

Unfortunately, the error message does not help me a lot (I would guess this is generated by either VS code or the debug engine itself, not my extension). Do you have changed any settings for the "Child Debugger" in VS code? Especially the setting to filter child processes could be relevant, since I just recently fixed a few bugs related to it and there could be more.

Then, it would be interesting to know whether you can see entries like:

On CustomMessage (Debugger PID XXX)
  MessageCode 1

in the ChildDebugger.log file when the error appears in VS Code (message Code 1, would indicate the settings message). This would mean that the message has at least been received. Otherwise there was an error when transmitting the message (which, at the moment, I would have no clue what could be the reason for that.)

albertziegenhagel commented 1 month ago

@jasonwilliams Could you retry your application with the newest pre-release? Note that the new *.vsix package from https://github.com/albertziegenhagel/childdebugger-vscode/releases/tag/head includes the debug engine extension binaries and automatically integrates with the debug engine, so I would suggest you delete the old, manual integration - especially the *.link file in $HOME/.cppvsdbg/extensions - and then just install the new extension package in VS Code.

I fixed a few issues that could have been the reason for your issues. Mainly:

edit: While I started to work on #12, I realized that I get exactly the error message you have reported above. Is it possible that your new application is a 32-bit application?

edit2: #12 was now resolved by #19, so hopefully this should now really fix your issues.

jasonwilliams commented 1 month ago

Yes, it is a 32bit application which spawns 64bit processes (what makes you ask this?). Still looking at the rest but its still not working as expected, this could be on our side though so I won't hold you account for this, i don't see the errors anymore

albertziegenhagel commented 1 month ago

Good to hear that you are not seeing any of the errors anymore. Let me know if there is anything else I can help with.