Breakpoints rematerializing in "…AutoDownloadedSources…"

[Ophidian14]

Hello,

My project is laid out in source and header files like the following:

src/Module1/Submodule1/Class1.h
src/Module1/Submodule1/Class1.cpp
src/Module1/Submodule2/Class2.h
src/Module1/Submodule2/Class2.cpp
src/Module2/Submodule3/Class3.h
src/Module2/Submodule3/Class3.cpp
src/Module2/Submodule4/Class4.h
src/Module2/Submodule4/Class4.cpp


(The numbering is not important, I am just giving an overview of the file tree structure).

The include path when compiling with my own Makefile is "src/", so for example, Class4.cpp might start with:

#include "Module2/Submodule4/Class4.h"

Because of this, I have to add “src” as an Intellisense path in my VisualGDB settings, and this all works fairly well.  So far so good.  Also I should add, I have my sources mounted via Samba, i.e. they are visible at \\10.0.0.1\myusername\src.

The problem comes when I go to set a breakpoint.  Say I open Class4.cpp and set a breakpoint on some executable line, and then run my project via gdb.   A few seconds into the startup process, the red dot on the breakpoint line will vanish, so it appears like the breakpoint is not set any more.

Then, when execution actually comes and hits my breakpoint, a second version of the file actually appears, and it is at the path “C:\Users\myusername\AppData\Local\VisualGDB\AutoDownloadedSources\myservername\src\Module2\Submodule4\Class4.cpp”.

This is distracting for a few reasons, but mostly these two:

1.)  Often I might discover a bug and I want to start editing the file immediately after I end the debugging session.  But I don’t realize I’m looking at the “copied” version of the file, so it starts bugging me that the file is read only and so on.

2.)  It’s not clear where I have or don’t have breakpoints just by looking at versions of the file that I open from Solution Explorer.

So my questions are:

1.)  What is the purpose of “AutoDownloadedFiles”?  What does it represent?

2.)  Is this the expected behavior?
3.)  Either way, is there some way my breakpoints can “only apply” to my actual source files and not the downloaded versions?

• This topic was modified 8 years ago by Ophidian14.

[support]

Hi,

VisualGDB uses the AutoDownloadedFiles folder for sources on the remote machine that were are not covered by path mappings known to VisualGDB (e.g. if your code uses a library with debug sources in /usr/src/<something>). Based on your description, VisualGDB cannot automatically detect that Windows folder that corresponds to the remote Linux folder, so it tries to download the files. This could be fixed very easily by adding a manual mapping on the Path Mapping page of VisualGDB Project Properties.

[Ophidian14]

Okay, thanks;  I added a “default absolute mapping” and this seemed to work the best.  When I added specific path mappings it didn’t seem to have an effect and when I added a “relative” path I started getting errors that it couldn’t find #include <set> and etc.

[Ophidian14]

Sorry, when I do a default absolute mapping then I lose Intellisense for builtin’s like printf() and etc.  I get an error in yellow at the top saying “Could not find   set and 70 other files”.  Any idea why that would be?

[Ophidian14]

Double sorry, I had deleted my RemoteDownloadedSourceCache folder by accident earlier in an attempt to get this working.

[Ophidian14]

I’m very apologetic as I don’t mean to spam this thread but I’ve noticed something else which is quite odd.  When the breakpoint hits, it still materializes a new window, HOWEVER, this window is the properly named (i.e. \\10.0.0.01\…) version of the file and not the AutoDownloadedSources version.  But if I already had that file open in my editor, then there are duplicate windows of the file open, and I start getting warnings saying instance A has been edited if I save instance B and vice versa.  Meanwhile, I eventually get a deluge of Clang Intellisense errors telling me that I have duplicate definitions of all the methods in the file!  Did I do something wrong?

[support]

Hi,

No problem. BTW, if you want to add more text to the previous post instead of creating another one, you can use the ‘edit’ link.

Regarding the extra windows, most likely there is still some small mismatch between the paths. Please right-click on the tab header and select “Copy full path” for both tabs and compare the paths side-by-side in an editor.

Regarding Clang IntelliSense errors, again it is most likely caused by some small typos in include paths. We would recommend using VisualGDB 5.2 that will show a special hint if an include file is missing and will help you locating it via the Browse button and will then adjust the IntelliSense settings. If this does not help, please let us know the details on the errors you are observing and we will help you diagnose them.

[Ophidian14]

That was it!!  The source file in GDB was the actual, hard path to the file and I’m accessing my source files via symlinks.  The paths are just slightly different.  I will update my mapping rule and try again.

[Author]

Posts