[Solved] C::B Watches window acting weird

[stuarte]

Hi,

I have developed a small C program to sort a 2d array of 4 strings.
Before sorting, the Watches window shows the array to have only two elements, names[0] and names[1].

In the Watches window :-
a) names[0] is shown to contain "Florida", '\000' <repeats 12 tiimes>, "Oregon", '\000' <repeats 13
b) names[1] is shown to contain "Georgia", '\000' <repeats 12 times>

The array entry for the third string, California, is missing from the Watches window.

After sorting, in the Watches window :-
names[0] is shown to contain "Florida", '\000' <repeats 12 times>, "California\000\000\000\000\0
names[1] is shown to contain "Georgia\000ia\000\000\000\000\000\000\000\000\000"
names[2] is shown to contain "Oregon", '\000' <repeats 13 times>

Why does the Watches window show only 2 array elements (i.e. names[0] and names[1]) before sorting and three array elements (i.e. names[0], names[1], and names[2]) after sorting ?

Why does the Watches window show more than one array element/string on the same line as though they are part of the same array element ?

Shouldn't the Watches window display each array element/string on its own line ?

[BlueHazzard]

This is probably a parsing error.
Can you enable full debug logging (settings->debugger->Common->Full (Debug) log) and post the debug log (from the debugger tab at the log panel) after sorting the watches here?
Also can you post example code what you are using?

[stuarte]

Hi BlueHazzard,

Than you for such a swift reply. First, the Watches window does not seem to allow "copy & paste" and so I am thereby unable to provide the contents of the Watches window here.

ASIDE: The site is not allowing me to attach two files to my reply. Could you please advise on how to fix this problem first.

Stuart

[Pecan]

Hi BlueHazzard,

Than you for such a swift reply. First, the Watches window does not seem to allow "copy & paste" and so I am thereby unable to provide the contents of the Watches window here.

ASIDE: The site is not allowing me to attach two files to my reply. Could you please advise on how to fix this problem first.

Stuart

I've had the "attach problem" before also. It was because there were utf8 chars in the text. Make sure the text has only ascii chars (values below 256).

[stuarte]

Good morning all,

@Pecan: Very(!) early this morning I found out how to change the underlying encoding in C::B. This has allowed me to attach both files as required. I would never have guessed that the underlying encoding was the problem. Thank you very much for that "heads up".

@BlueHazzard: Now that the file attachment problem has been fixed, please find attached the debug log in file "debug_log.txt" and the offending code in file "main.txt". Please note that after changing the underlying encoding to ASCII the program was then rebuilt and executed. This change to the underlying encoding made no difference to how things appeared in the C::B Watches window. Consequently I have attached the full debug log obtained prior to this change to the underlying encoding.

Please also accept my apologies for the tardiness of this reply.

Stuart

[BlueHazzard]

Hi, i can reproduce your bug, but i am afraid we can not do anything about this easily (more at the end)....

I have modified your example like this:

Code

#define strLength 60

/* function prototypes */
void sort(char [][strLength], int);
/* void swap(char [], char []);  */

int main(void)
{
   char names[4][strLength] = {"Florida000000000000000000000xxxxxxxxxxxxxxxxxxxxxx",
                               "Oregon",
                               "California",
                               "Georgia"};

now if we look at the output of the gdb log we get this:

Code

> output names
->{"Florida", '0' <repeats 21 times>, 'x' <repeats 22 times>, "\000\000\000\000\000\000\000\000\000", "Oregon", '\000' <repeats 53 times>, "California", '\000' <repeats 49 times>, "Georgia", '\000' <repeats 52 times>}

as here is visible gdb does not give us any hints where the nested array is ending (the names) and where the next is starting. As you would expect because internally a multi dimensional array in c is a continuous memory block.
The only way to distinguishe this would be to count the actual elements. So first look at the output of the what is call

Code

> whatis names
->type = char [4][60]

and then parse the output of "names" accordingly by counting all characters and <repeats x times> occurrences.
This will probably not happen....
 
AndrewCot is currently working on a new type of gdb plugin, that makes output parsing a lot better (see https://forums.codeblocks.org/index.php/topic,25058.0.html ) I will look into this the next week and i think we will probably introduce this plugin in codeblocks in the future for a better debugging experience.
I have not tested it until now, so i do not know exactly if this "quirk" you have reported is different in the new plugin...

[AndrewCot]

I have not seen a GDB client for DAP. If anyone knows of one or finds one please let me know as I would like to test it.

I will put this on my list, but due to the slow progress I am making with getting the ProjectExport Cmake output files working with the C::B project files I think BlueHazzard will get to check it out before me. I will check the GDB/MI plugin to see if it works or not, but this plugin is only available as source and as such is not available for non C::B devs to try.

[BlueHazzard]

I have not seen a GDB client for DAP. If anyone knows of one or finds one please let me know as I would like to test it.

Oh... i was thinking visual studio has a DAP for GDB? Is this only for llvm? Anyway, will check it out, with time comes for sure a DAP plugin for gdb, so i think investing in this plugin is a good idea.

In the mean time i have found a fix for this. You can enter the following command in the debugger command field (in the debugger log is a field where you can enter commands at the bottom):

Code

set print array on

And re add the variables to the watches. This should fix the print problem. I am investigating a bit and probably commit an auto call to this in the gdb plugin...

[AndrewCot]

Just got back to this one.

You should be able use the GDB debugger initialization commands to send the command automatically to GDB. This is done via the Settings->Debugger... menu and then on the left select the debugger you are using and then enter the command in the 'Debugger initialization commands" text box and press OK. I have used this to load the python pretty printers in the past.

It is my understanding that Visual Studio Code (VSC) GDB interface uses the GDM/MI interface as the DAP interface was only added a few years ago, but GDB has been available for years before that, but I could be wrong. VSC LLDB debugger does use the DAP interface and so do a number of the other debuggers for other languages. DAP is from VSC, but has been added to a number of other IDE's all ready and the list is growing as time progresses. I agree with the DAP GDB & DAP plugin feedback.

[stuarte]

Good morning gentlemen,

First, please accept my apologies for the tardiness of this reply.

@AndrewCot: I have followed your advice and entered the "set print array on" into the Debugger initialization commands box in Settings/Debugger.../default. I then single-stepped the program and found that both before and after sorting the Watches window now showed each element of names[] on its own line, that is names[0] on the first line, names[1] on the second line and so on.

@BlueHazzard: Having implemented Mr Cot's advice and found it to work, do I also need to enter the "set print array on" command into the debugger command field (in the debugger log) or are these two different ways to achieve the same result ?

Anyway, I would like to thank you gentlemen for your very responsive help in this particular matter and the whole team for bringing forth C::B in the first place and thereby making debugger access and usage (at least at the basic level) so very easy.

Stuart

[BlueHazzard]

do I also need to enter the "set print array on" command into the debugger command field (in the debugger log) or are these two different ways to achieve the same result

No need. Andrews way is a permanent way, if you follow my way you have to do it every time you restart the debugger. So his way is better