Forum Replies Created
-
AuthorPosts
-
BitFlipperParticipant
Sorry for the belated reply…
I had a chance to try and repro this with a simple project, however I cannot get it to repro the issue except in my main project. My main project is a Custom project using NMake that runs GDB on a remote system (not GDB server). So it is not MinGW-based. I’m not sure if that could be related.
Anyway, I played with creating a similar Custom project that uses NMake, but could not get it to repro the issue that I see in my main project. If I have more time I’ll continue to narrow down the issue further and post again once I have more info.
Thanks
BitFlipperParticipantI have confirmed that it runs the command if placed under Before launching debugger, but it does not run if placed under After debugger exits. I need the script to run after the debugger exits.
BitFlipperParticipantThe project is already set up to strip most of the libs (each have 3 versions: full, stripped, symbols-only). So I can work on configuring it using your suggestions above.
Thanks for the help!
BitFlipperParticipantThanks for the reply!
Strange, I posted a reply the same day after the original post saying I was able to figure it out. However, for some reason that post is gone now. Not sure why.
I have the Custom version, so I was able to get it to work with some trial and error.
BitFlipperParticipantOk that doesn’t make much sense to me.
In that case, can you tell me how to deactivate/reactivate the license for an installation so that I can enable just the specific one I need to work on at the time?
Thanks.
- This reply was modified 6 years, 7 months ago by BitFlipper.
January 16, 2018 at 00:39 in reply to: Possible to change location of VisualGDB-DisownTTY-r1? #13472BitFlipperParticipantAh excellent, thanks for the really fast response 🙂
BitFlipperParticipantOK thanks for confirming. I’ll take a look at your C# visualizer API.
Can you also maybe clarify about the “stepping through” issue. I realize this might be a completely different issue. Basically, when I have something like a shared_ptr<MyClass> instance, and I step through/into the code, I want to step directly into methods inside the MyClass instance, not first have to step through the shared_ptr member functions before getting into the MyClass members.
BitFlipperParticipantI got the natvis visualizer to more or less work with the following:
<Type Name="std::shared_ptr<*>"> <DisplayString Condition="_M_ptr == 0">null</DisplayString> <DisplayString Condition="_M_ptr != 0">{*_M_ptr}</DisplayString> <Expand> <Item Condition="_M_ptr != 0" Name="[ptr]">_M_ptr</Item> </Expand> </Type>
It works for things like shared_ptr<int> and shared_ptr<MyClass>, however it doesn’t work with shared_ptr<string>. Strangely, a string by itself works (i.e. it shows the string contents while hovering over a string variable), but shared_ptr<string> doesn’t display the string value properly.
The full string type is:
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>
Is there an issue with making it work with nested template types, or am I just doing it wrong?
- This reply was modified 6 years, 11 months ago by BitFlipper.
BitFlipperParticipantNote I’m not using native VS intellisense.
I should clarify since I made a typo above, I am using native VS intellisense, not Clang intellisense. Not sure if it matters either way.
BitFlipperParticipantI guess I need to use the Natvis support in VS, however I can’t get it to work after trying a few times. Can someone provide an example of what a Natvis file would look like that properly shows a std::shared_ptr<>?
BitFlipperParticipantOops, sorry to say thanks, I realized later that since I was using template functions, it was inserting a breakpoint for each type for which it created a template function. As for the slow response, never figure out what that was. It did eventually seem to go away as it might have had something to do with path mappings that were not set up properly at that time.
BitFlipperParticipantYes this successfully works around the issue! After setting the custom break command in Custom Debug Steps, setting/clearing breakpoints and doing Break All are very reliable now.
Thanks for you help with this!
BitFlipperParticipantOK I will try to gather more info (although I have just this one setup now so not sure when I can try other setups). Here are some other datapoints:
It seems to happen randomly, with roughly 90% of the time not being able to set a breakpoint while the debugee is running. The other 10% of the time it successfully sets the breakpoint while the debugee is running. It also doesn’t seem to matter where the breakpoint is placed, e.g., one moment it will work fine in a specific location, then press F5 and suddenly it will no longer be able to set a breakpoint again at the exact same location where it worked before during the same debug session.
When it works I can see the breakpoint activity in the GDB Session raw output window. When it doesn’t work, there is no activity in the GDB Session raw output window other than the single new “&”Quit\n” line.
Also, when it doesn’t work (i.e. 90% of the time), I need to kill the debug session and place breakpoints ahead of time before starting a new debug session again. This is annoying since I often need to place breakpoints after the fact (e.g. code that has already executed 1000’s of times), or alternatively rely on conditional breakpoints which has a big impact on performance.
Probably related: 90% of the time when doing “Break All”, it also fails with the single “&”Quit\n” line in the GDB Session raw output window. At that point I need to kill the debug session and start a new one.
If it helps, I’m running the debugee on Ubuntu 16.04 x64, debugging a Qt application. VS 2015 Pro Update 3, VGDB 5.2R9 (build 1452).
- This reply was modified 7 years, 6 months ago by BitFlipper.
BitFlipperParticipantI figured out what the issue was. As mentioned before, there were no paths set in “Additional source path mappings”. After I added a mapping there, I’m able to set breakpoints while the app is running and it will hit them. So it is unclear why it can resolve them while the app is not running or while it is stopped in the debugger, but not while running in the debugger.Anyway it is working now so thanks for the help.EDIT: I spoke too soon. It just started behaving the same again so setting the path mapping wasn’t the solution it seems. I don’t know why it worked for a short while, then started behaving the way described earlier.
Any ideas?
- This reply was modified 7 years, 6 months ago by BitFlipper.
BitFlipperParticipantThe loop is not infinite, so the remaining code is not optimized out. In fact, if I place a breakpoint in the loop before I start debugging, when it hits the breakpoint in the loop I can then place breakpoints later in the main function (or anywhere else) and it will successfully hit it.
To clarify: While the app is running and I try to place breakpoints, the following happens:
- I get the “GDB Timeout” dialog, which doesn’t go away again even after 10 minutes.
- If I click “Stop debugging” in the dialog, debugging obviously stops.
- If I click “Retry break-in”, nothing seems to happen.
- If I click “Cancel break-in”, sometimes the dialog goes away and the breakpoint is shown as sold, however it isn’t hit.
- Other times when I click “Cancel break-in”, the “GDB Timeout” dialog pops up a second time, and when I click “Cancel break-in” again, I get a “Microsoft Visual Studio” error dialog stating the breakpoint could not be set. The breakpoint is then shown as not solid, and the tooltip shows the breakpoint is not valid.
- If I click on “Diagnose breakpoint problems”, a “VisualGDB” dialog pops up and says no breakpoint problems were detected. This is while the breakpoint is shown as having problems.
- Every time I try to set a new breakpoint, the raw GDB session output only shows a new line with “&”Quit\n”.
It is important to note again that if breakpoints are set before debugging starts, or after another breakpoint was hit and it is currently stopped in the debugger, that any new breakpoints at that point will be set correctly without any issues.
The problem seems more related to stopping the debugee successfully in order to set the new breakpoint (which is what I think VGDB needs to do), not resolving symbols. But that is just my guess.
-
AuthorPosts