[BitFlipper]

I have since noticed that the whole list of aliases gets deleted simply by going to the SSH connections dialog and looking at the list of aliases. I was in a debugging session and right after it finished I went into the SSH connections settings and all aliases were gone.

Once the aliases are gone, if I then open the VGDB settings, it first shows a dialog complaining about the missing aliases and when closing the dialog box, only shows a blank page in the settings dialog.

Definitely a bug.

[BitFlipper]

OK I have a follow up question related to using gdbserver…

Note however that I’m using VGDB for debugging only as I already have an extensive dev framework that compiles/deploys the project. So I don’t want VGDB to compile or copy any files anywhere. Right now I already have VGDB doing only debugging, but this fact might be relevant when considering the below question…

So IIUC, when using gdbserver, the setting under “Project settings > Remote machine > Deploy executable on a different machine” …must be selected? If not, will GDB run on the same machine where gdbserver runs, which will defeat the purpose? So just to be clear, the address I enter here is where GDB will actually run, even though it specifically refers to where the executable will be deployed?

[BitFlipper]

OK thanks that worked. However now I’m running into a different problem… It seems VGDB is running out of memory as it loads a huge amount of symbols. I’ll need to figure out how to limit which symbols are loaded.

[BitFlipper]

I actually found out that adding the following as part of the gdb command for the PID works:

pidof my_program

This assumes there is only 1 instance of my_program running at the time.

 

[EDIT] It appears the forum software is removing the grave accents from the above command. It needs to be inside “`”.

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

[BitFlipper]

OK thanks I’ll give it a try!

[BitFlipper]

I believe I was able to resolve the file mapping issue. The main problem here was my misunderstanding of what some of the settings under “File synchronization” means. I was under the impression that this was only needed when you want to sync files between systems, which I don’t need. However it seems that both “Local directory” and “Remote directory” actually play a role in how file mapping is resolved at debug time, regardless of what manual mappings you add.

For instance, if you leave “Remote directory” blank, then you can reproduce the issue where the local Windows paths always have the remote path appended at the end.

I am still not able to resolve the issue with some breakpoint that show as unresolved but that are hit correctly. My efforts to reproduce this with the hello world application did not succeed. I will do some more testing tomorrow and hope to provide some more info then.

[BitFlipper]

I wonder if this could be related to the fact that VGDB is used in a non-standard way in our case. We change the build, rebuild and clean command line settings in the VS NMake project to that of our own tool. So VGDB does not partake in any of the build phases so maybe it is causing some issues. VGDB does complain that the VS project settings are inconsistent but up until this issue we have not seen any other side effects that interfere with the debugging functionality.

I will try to repro this first with a hello world application since it will be easier to share the logs.

EDIT: In the meantime here is some relevant info…

Windows 7 Enterprise SP1 x64
VS Ultimate 2012 Update 4
VisualGDB 4.1
Debug OS: SLES 11, Kernel 3.0.13-0.27-default
GDB 7.3-0.6.1

[BitFlipper]

OK I will try to send you the VGDB log later today. Where can I send it to as I don’t want to post it here publicly?

[BitFlipper]

I have to make a correction to one of my previous comments… I said only one file was listed when I did “info sources”. I did not realize it listed all files on the same line. After looking at all files listed, I can see that it shows every file where I’m setting breakpoints. So the error shown by VGDB:

“The currently loaded GDB symbols have no record of any file called…”

…is confusing since “info sources” does show the file in question. Here is another weird thing: For one source file, the breakpoint is resolved successfully and shown as resolved. For another file in the same executable, it shows the breakpoint as unresolved but the breakpoint is hit. Both files are listed in “info sources”.

@bazis wrote:

Does the breakpoint reply contain the address it was resolved to or is it marked as ‘pending’? Can you send us the full GDB log? This will help us diagnose the problem further.

My company has strict policies regarding source code so I can’t give the exact file name paths, function names etc. So I will find/replace source code paths and function names to make it generic. But you should still be able to see the issue below.

So when I put a breakpoint on the first file (source1.c) where it resolves it properly (although it can take up to 30 seconds to place the breakpoint), the GDB output is as follows:

^done,bkpt={number=”9″,type=”breakpoint”,disp=”keep”,enabled=”y”,addr=”0x00007ffff50613d8″,func=”api1_connect”,file=”/usr/buildmachineproject/projectname/sources1/source1.c”,line=”4026″,times=”0″,original-location=”/usr/buildmachineproject/projectname/sources1/source1.c:4026″}
-break-info 9
^done,BreakpointTable={nr_rows=”1″,nr_cols=”6″,hdr=[{width=”7″,alignment=”-1″,col_name=”number”,colhdr=”Num”},{width=”14″,alignment=”-1″,col_name=”type”,colhdr=”Type”},{width=”4″,alignment=”-1″,col_name=”disp”,colhdr=”Disp”},{width=”3″,alignment=”-1″,col_name=”enabled”,colhdr=”Enb”},{width=”18″,alignment=”-1″,col_name=”addr”,colhdr=”Address”},{width=”40″,alignment=”2″,col_name=”what”,colhdr=”What”}],body=[bkpt={number=”9″,type=”breakpoint”,disp=”keep”,enabled=”y”,addr=”0x00007ffff50613d8″,func=”api1_connect”,file=”/usr/buildmachineproject/projectname/sources1/source1.c”,line=”4026″,times=”0″,original-location=”/usr/buildmachineproject/projectname/sources1/source1.c:4026″}]}
-break-after 9 0
OK
info symbol 0x7ffff50613d8
&”info symbol 0x7ffff50613d8n”
api1_connect + 30 in section .text of /usr/lib/company-foo-apilib/lib64/libApi.so
OK
info line *0x7ffff50613d8
&”info line *0x7ffff50613d8n”
Line 4026 of “/usr/buildmachineproject/projectname/sources1/source1.c” starts at address 0x7ffff50613d8 and ends at 0x7ffff50613e0 .
OK

Now when I put a breakpoint on a line in the second file (source2.c) where it says the breakpoint is unresolved, yet it still hits the breakpoint, the GDB output looks like:

-break-insert -f /usr/buildmachineproject/projectname/lib/apilib/source2.c:539
^done,bkpt={number=”7″,type=”breakpoint”,disp=”keep”,enabled=”y”,addr=”“,times=”0″,original-location=”/usr/buildmachineproject/projectname/lib/apilib/source2.c:539”}
-break-info 7
^done,BreakpointTable={nr_rows=”1″,nr_cols=”6″,hdr=[{width=”7″,alignment=”-1″,col_name=”number”,colhdr=”Num”},{width=”14″,alignment=”-1″,col_name=”type”,colhdr=”Type”},{width=”4″,alignment=”-1″,col_name=”disp”,colhdr=”Disp”},{width=”3″,alignment=”-1″,col_name=”enabled”,colhdr=”Enb”},{width=”18″,alignment=”-1″,col_name=”addr”,colhdr=”Address”},{width=”40″,alignment=”2″,col_name=”what”,colhdr=”What”}],body=[bkpt={number=”7″,type=”breakpoint”,disp=”keep”,enabled=”y”,addr=”“,times=”0″,original-location=”/usr/buildmachineproject/projectname/lib/apilib/source2.c:539”}]}
-break-after 7 0
OK

The manual mapping should work with any path prefix (try restarting debug session if it’s not updated immediately). E.g. if you want to map /usr/buildmachineproject/code/somefolder to c:projectcodesomefolder, you need to create the following mapping:

Linux path: /usr/buildmachineproject/code
Windows path: c:projectcode

If this still does not work, please send us the screenshots of your source file mapping window and the window showing incorrectly mapped paths.

That is pretty much how I set up the mapping. Using the same path structure as in the above GDB output, it looks like:

Linux path: /usr/buildmachineproject/projectname
Windows path: c:projectname

Then the reported mapping looks like:

Linux path: /usr/buildmachineproject/projectname/sources1/source1.c
Windows path: usrbuildmachineprojectprojectnamesources1source1.c

So it ignores the specified Windows path. However note I unchecked the “Use project directory” option under “File synchronization” and also cleared the “Local directory” path. Whatever I put in there will simply be prepended to the Windows path listed above, so it will always contain the “usrbuildmachineprojectprojectname” part.

I will try to provide as much info as required, but I might not be able to provide VGDB logs due to my company’s strict source code policies. Let me know what other info you require and I will see what I can do.

[BitFlipper]

Note for the build machine path I changed “project” to “buildmachineproject” to make things clearer.

@bazis wrote:

2. Set a breakpoint in a problematic file. VisualGDB will issue a -break-insert command. GDB will report whether it has been resolved.

When I set a breakpoint, it takes a long time (~15 seconds), then the output appears to show success. It shows the correct path to the file as it was on the build machine, ie:

/usr/buildmachineproject/code/somefile.c

However VS shows the breakpoint as unresolved. When I click on “Diagnose breakpoint problems”, VGDB lists the file as problematic and the error message shows “The currently loaded GDB symbols have no record of any file called …”.

This breakpoint actually gets hit successfully though.

* info shared – this will show the loaded shared libraries. Ensure that the library that contains your code is loaded.

All libraries appear to be loaded successfully and all show “Yes” for “Syms Read”.

* info sources – this will list all source files known to GDB

This shows only one source file (a different one), and the full path is of the build machine pov. It also shows one other file for which symbols will be loaded on demand.

So the question is: Does the Linux debug machine need to have copies of the source files as well? Some files can have breakpoints set successfully so it seems it should not be required.

Something else that may be relevant… When I click on “Show a list of all source files”, I get a list that looks like this:

/usr/buildmachineproject/code/somefolder/source.c -> C:ProjectCodeusrbuildmachineprojectcodesomefoldersource.c

So it is appending the full build machine path to the local path.

I did the following tests… I cleared all manually added path mappings, then in VGDB Project settings under “File synchronization”, if I uncheck “Use project directory” and clear the path there, then the path mapping is reported as:

/usr/buildmachineproject/code/somefolder/source.c -> usrbuildmachineprojectcodesomefoldersource.c

So it is still wrong.

Next, whatever local path I put into the path in File synchronization, it gets prepended to the reported local path. So if I put “C:ProjectDummyPathCode” in there, the reported mapping looks like:

/usr/buildmachineproject/code/somefolder/source.c -> C:ProjectDummyPathCodeusrbuildmachineprojectcodesomefoldersource.c

No matter which path mapping I enter manually, they don’t seem to be honored, instead it always seem to use the above logic. So I’m unsure how to resolve the path mapping for my use case. I did check the gdb version, it is 7.3-0.6.1 which is pretty old I think. It might cause the issue, not sure.

Any more ideas?

Another question I have… Is it only necessary to add a path mapping to root paths, or do you need to add a mapping for each and every folder?

[BitFlipper]

@bazis wrote:

Hi,

Thanks for pointing this out. We will add an update to our next release. Please let us know whether you need a hotfix before the release.

For now we can work around it so it is not urgent but it would be nice to have a fix for this in your next release 🙂

[BitFlipper]

OK I figured most of this this out now. I can successfully configure VGDB’s SSH connections from my automated configuration tool. The only problem I’m still running into is that VGDB only loads SSH connection info at the time when the VS project is opened. So you can open two instances of VS, set up a connection in one, and the other one will not see the connection until you exit and re-open VS. Sometimes it even gets confused and shows the same connection twice, etc.

Also when trying to debug with a valid connection, it would sometimes say there is no such connection even though it is configured in all the right places. It seems ideally it should reload connection info when the SSH connection dialog is opened, and also when starting to debug.

Once again I know my use case is not normal but I can see VGDB getting confused with SSH connections when you have more than one VS instance open, which I think many people do, at least where I work since we work on multiple source code branches at the same time.

[BitFlipper]

OK I think I partially figured it out…

It seems the VGDB SSH Connection Manager only loads/saves SSH connection info when VS opens/closes. This means that if you have multiple VS instances open, the SSH Connection Manager in one instance can get out of sync with another one. Ideally they should load/save the info when the connection manager itself is opened/closed. This is not just for my own use case but in general it seems it would be better to do it that way because one can set up new connections in one VS instance, then close VS, then if the other instance is closed, it could wipe out the new connection again.

Having said that, if I first close all instances of VS and then run my tool to configure everything, VGDB will pick up the new connection although it complains the key has been modified. Accepting the modified key then results in a successful VGDB connect attempt. Much better but not ideal due to possible loss of connection settings if the user forgot to close all VS instances.

[BitFlipper]

OK I believe I found the cause of this issue. I was getting a lot of SIG exceptions while debugging the application so previously I added these GDB startup commands:

handle SIGPWR nostop pass
handle SIGXCPU nostop pass
handle SIG35 nostop pass
handle SIGSEGV nostop pass
handle SIGINT nostop pass

It seems at least one of those were causing VisualGDB to stop functioning properly. I removed them all and now I can place breakpoints without the application crashing, however debugging is almost impossible since I get tons of SIGPWR and SIGXCPU exceptions thrown continuosly.

But this then brings me to the question of how to get rid of or suppress these exceptions? If I can add them to the VS exception list and then ignore them that way it would help, but I’m not sure which category to add it to. Any ideas?

EDIT: Just found this that describes how debugging Mono (I’m using Mono to P/Invoke into native code) will confuse GDB, and which signals to ignore. So I’ll add…

handle SIGXCPU SIG33 SIG35 SIGPWR nostop noprint

…and see if that solves the non-stop barrage of exceptions.

EDIT EDIT: Once I added the above GDB startup command it now works properly, so problem solved!

[BitFlipper]

OK here is some more info that may be relevant…

I am using 3 systems:

1. Windows dev system
2. Linux build system
3. Linux debug system.

The source code is synced between the Windows and Linux build system, but not the Linux debug system. Since this “almost” works, does the 3rd system really need the source code as well? The debug system does not have space to store all the source code so it could be a problem if that is a requirement.

Also, how does path mapping need to be set up in the above scenario?

[Author]

Posts