[BitFlipper]

I believe I used a Linux project wizard. But this is years ago, and since then I simply copy the .vgdbsettings file to any new VS project I create since it is just another instance of the same source git repository.

I’m 100% sure neither of the Treads window nor the Parallel Stacks window is open. Also, since I still see multiple duplicate GDB commands issued for each single step as shown in my previous reply, the version I’m using doesn’t seem to contain the optimizations you mention. But I have confirmed that it is v 5.2 Beta 2, so I don’t know why I’m not seeing these optimizations. I looked through all of the settings to see if it is optional, but nothing seemed to indicate that it is an optional optimization.

[BitFlipper]

I finally got some time to look further into the issue with the beta not working for me. I created a new test project I found there were two issues. One is that if the project has a “-” in its name, then the.vgdbsettings filename get renamed by replacing “-” with “_”. E.g, if the project name is “My-Project.vcxproj”, it will be renamed to something like “My_Project-Debug.vgdbsettings”.

The second problem was that in the old projects, the NMake Output values is set to “My-Project-Debug.vgdbsettings”, while in the beta project it is “$(ProjectDir)My-Project-Debug.vgdbsettings”. So there is a missing “$(ProjectDir)” when an old project is opened in the beta version. Maybe your path logic can add it automatically if it is missing in order to still support older projects.

So after fixing those two issues in my older projects, the beta works for me. However stepping is still as slow as always. I tried to play with all of the “Thread ans Execution” options but I still get the same repeated commands to GDB. I verified that I have 5.2 Beta 2. See the output from below of one single step:

[   27717 ms] -exec-next
[   28153 ms] -stack-list-frames –thread 9
[   28207 ms] -stack-list-frames –thread 9
[   28211 ms] -stack-list-arguments –thread 9 1
[   28263 ms] -stack-list-frames –thread 9
[   28266 ms] -stack-list-arguments –thread 9 0
[   28323 ms] -stack-list-frames –thread 1
[   28325 ms] -stack-list-arguments –thread 1 0
[   28340 ms] -stack-list-frames –thread 1
[   28342 ms] -stack-list-arguments –thread 1 0
[   28350 ms] -stack-list-frames –thread 2
[   28362 ms] -stack-list-arguments –thread 2 0
[   28447 ms] -stack-list-frames –thread 2
[   28451 ms] -stack-list-arguments –thread 2 0
[   28532 ms] -stack-list-frames –thread 3
[   28544 ms] -stack-list-arguments –thread 3 0
[   28692 ms] -stack-list-frames –thread 3
[   28698 ms] -stack-list-arguments –thread 3 0
[   28911 ms] -stack-list-frames –thread 4
[   28927 ms] -stack-list-arguments –thread 4 0
[   29093 ms] -stack-list-frames –thread 4
[   29100 ms] -stack-list-arguments –thread 4 0
[   29355 ms] -stack-list-frames –thread 5
[   29370 ms] -stack-list-arguments –thread 5 0
[   29537 ms] -stack-list-frames –thread 5
[   29545 ms] -stack-list-arguments –thread 5 0
[   29765 ms] -stack-list-frames –thread 6
[   29785 ms] -stack-list-arguments –thread 6 0
[   30148 ms] -stack-list-frames –thread 6
[   30157 ms] -stack-list-arguments –thread 6 0
[   30421 ms] -stack-list-frames –thread 7
[   30431 ms] -stack-list-arguments –thread 7 0
[   30523 ms] -stack-list-frames –thread 7
[   30527 ms] -stack-list-arguments –thread 7 0
[   30658 ms] -stack-list-frames –thread 8
[   30663 ms] -stack-list-arguments –thread 8 0
[   30686 ms] -stack-list-frames –thread 8
[   30689 ms] -stack-list-arguments –thread 8 0
[   30773 ms] -stack-list-frames –thread 9
[   30779 ms] -stack-list-arguments –thread 9 0
[   30821 ms] -stack-list-frames –thread 10
[   30825 ms] -stack-list-arguments –thread 10 0
[   30833 ms] -stack-list-frames –thread 10
[   30836 ms] -stack-list-arguments –thread 10 0

 

When I execute “thread apply all bt”, it takes 311 ms (10 x faster) and shows all required stack info AFAICT. It seems like a much faster way to do it, except if the improvements you mention above also solves the problem.

• This reply was modified 8 years, 1 month ago by BitFlipper.
• This reply was modified 8 years, 1 month ago by BitFlipper.

[BitFlipper]

I have reverted to 5.1 for now, but if you say the .vgdsettings name is using a different way to locate the .vgdbsettings file then that must be the problem.

My .vgdbsettings file is named like this:

MyProject.vcxproj
MyProject-MyProject.vgdbsettings

I’m not sure why it is following that specific naming pattern but IIRC that is the pattern I originally saw the 1st time I created a VGDB project a few years ago.

So are you saying that if I change the name to MyProject.vgdbsettings that it should then work? My deadlines are very aggressive so I’m hesitant to make drastic changes (upgrade to beta version for instance) to my dev environment since it is quite elaborate and TBH, a bit fragile.

Thanks again in advance for any help with this.

[BitFlipper]

After upgrading to VGDB 5.2. Beta 2, the VGDB project settings on the context menu is gone. Did something change that could cause this? When I press F5, it says the *.vgdbsettings file does not exist. I went into the VS NMake properties of the project and noticed the “Output” value of *vgdbsettings file name was changed, with “-” converted to “_”. I changed them back, but still got an error that the *.vgdbsettings file is not a valid Win32 executable.

Next I created a new test solution with a VGDB project. The wizard wanted me to enter the build/debug machine’s info, which I did. But it then tried to build something there which is not what I use VGDB for. I only use it for debugging alone, not building or deploying. I was able to configure the previous version of VGDB to only debug. In fact the debug machine has no ability to compile anything and this should not be required.

TBH I don’t remember exactly how I created the original VGDB project, so maybe I just didn’t go through the same wizard back then.

Can you let me know how to make VGDB 5.2. Beta 2 work the same way as 5.1 did? In the meantime I reverted back to 5.1 and now it works again.

Thanks in advance for any help with this.

• This reply was modified 8 years, 1 month ago by BitFlipper.

[BitFlipper]

Hi,

OK I will give it a try but I’m very hesitant of trying beta builds. Can I revert if it breaks something?

I did the following experiment:

1. Created a GDB command file with this content:
   # Step once and get stacks info from all threads
   define stepone
   step
   thread apply all bt
   end
2. Added the following under GDB Startup Commands:
   source <path to command file>
3. After hitting a breakpoint, execute the following command:
   stepone

The whole command takes about 300ms to execute, vs 3000ms. AFAICT, the backtraces contain the same info than what you get from all the individual commands that VGDB executes after each step or after hitting a breakpoint.

This should make a huge difference with slower connections. “Use a faster connection” just isn’t always a possible option.

[BitFlipper]

Excellent, thanks!

[BitFlipper]

I finally got a chance to look into this issue again… It seems to work in most cases, for instance I can select “Main build machine” in custom actions for debug steps etc. This will then use the host I specified in the above dialog you show. However AFAICT, there is no way to select “Main build machine” in the actions for custom shortcuts. In order to do one time setup of the debug host, I created a custom shortcut that runs a bunch of custom actions. So I need to be able to select “Main build machine” in custom shortcut actions too.

The solution I came up with of doing a find/replace of the host alias to use in each *.vgdbsettings file seems to work OK for now so this isn’t a big issue anymore, but it would be nice if a custom shortcut action can also select the “Main build machine” in its list of host options.

[BitFlipper]

Ah excellent, I’ll give that a try! Somehow I missed that.

[BitFlipper]

OK I’m not sure how I should do this. Say I have a custom shortcut that performs a lot different actions, with a typical action looking like this as displayed in its summary:

Run "some command" in directory "/bin" on MyDebugHost (alias)

So MyDebugHost is a global alias that is configured for a specific host. Now let’s say I have a second VS instance that has the same *.vgdbsettings file, with a few user variables changed between the different VS projects to customize for that specific instance. But all the actions in its custom shortcut are still the same. So if I run that custom shortcut on the 2nd VS instance, it will use the same target host, with no way to have each VS instance using a different target host (AFAICT).

The only way I can see is to create a second global host alias (say MyDebugHost2), and change all the actions in the 2nd VS instance’s VGDB settings to use MyDebugHost2. So this is the part that would be very time consuming.

Ideally, for each VC instance, I should just need to set one user variable like:

For VC instance 1:

DebugHostAlias=DebugHost1

…and for VC instance 2:

DebugHostAlias=DebugHost2

…where DebugHost1/2 etc are actual global host aliases. Then in the custom shortcut actions, I set DebugHostAlias as the host’s alias. However I can’t select DebugHostAlias as the target host in the actions since it isn’t really a global alias and hence doesn’t show up in the list of aliases.

So one way to make it work would be to allow typing of a host or user defined variable (that itself has a host alias for instance) name into the target computer field, as opposed to only allow selecting from the list only.

Let me know if there is a way to make it work.

Maybe one way to get close to what I need would be to just do a find/replace in each instance of the *.vgdbsettings files and set all aliases in each one to a different alias that way. Not as nice but at least that should work.

Thanks in advance for your help!

[BitFlipper]

OK thanks I’ll give this a try!

A follow up question… I’m not familiar with how this works, but if GDB starts a script (say python), that eventually causes the program to run, can I simply specify the script as the program to start, and will GDB eventually hit the breakpoints in the program? IOW, will the script’s sub-processes (and sub-sub-sub-etc-processes) still be considered to be debugged?

• This reply was modified 8 years, 2 months ago by BitFlipper.
• This reply was modified 8 years, 2 months ago by BitFlipper.

[BitFlipper]

BTW, the ideal way that I want this to work is as follows:

I already have a custom shortcut that I run once for each new debug host. It performs a bunch of operations like copy config files, mounts various shares to the debug host etc. I’d like to add another step to this shortcut that sets the user variable to the correct value for the particular path on the debug host. So basically, once I run that shortcut and it performs all the steps, the user variable should be set to the correct value, and I should see it in the list of user variables.

But as mentioned in the previous reply, I can’t get this to work. Please let me know what I’m doing wrong.

[BitFlipper]

I can’t get this to work properly. I’ve tried adding the custom action to “Custom build steps”, “Custom debug steps” and also as a “Custom shortcut”. In all 3 cases, when I click on the “Test command now” button, I get the following popup dialog:

Success:
TestVar=/the/correct/path

So the command is working properly for 3 of the above ways of configuring it. However the path mapping still does not work.

So for clarification, should the variable that I’m setting be a pre-existing variable (TestVar in this example)? I tried both with a non-existent variable, as well as a pre-existing user variable and it never works, unless I manually set the user variable to the correct value.

Also, I noticed that if I don’t create a pre-existing variable, it never shows up in the “View VGDB variables” window, even after successfully running the command.

Any idea what I’m doing wrong?

[BitFlipper]

Excellent, thanks! I’ll give it a try.

[BitFlipper]

Thanks for your help, it sounds like a solution to the problem.

However can you give me an example of how to store a value into a VGDB variable programmatically? I searched around but did not find an example.

[BitFlipper]

Please ignore the issue related to losing aliases. The bug is in my dev framework (a rogue script was doing bad things).

The other issue, #2 isn’t a big deal, just a nice to have.

[Author]

Posts