More debugger woes...

[tlovern]

debugger still doesn't evaluate local variables correctly....

simple code to illustrate the problem:

Code: Select all

#include <stddef>
#include <stdlib>
#include <stdio>
#include <string>

void subroutine(void);

int main(int argc, char **argv)
{

        subroutine();
        return 0;

}

void subroutine(void)
{

char    *temp,
        *temp2,
        value[512 + 1];



        strcpy(value, "abcdefghijklmnopqrstuvwxyz");
        temp = value;

        printf ("\n value = %s", value);
        printf ("\n temp  = %s", temp);

        temp2 = malloc(512 + 1);
        memset(temp2, 0, 512 + 1);

        printf ("\n temp2 = %s", temp2);

        return;
}
[End of file]

Here's the output without debug:

Code: Select all

$ r problem/nodeb

 value = abcdefghijklmnopqrstuvwxyz
 temp  = abcdefghijklmnopqrstuvwxyz
 temp2 =
$

above, we see the simple code works as expected. (real code I'm dealing with is several layers deep in much more complex code)

debug session:

Code: Select all

  4438: void subroutine(void)
  4439: {
  4440:
  4441: char    *temp,
  4442:         *temp2,
  4443:         value[512 + 1];
  4444:
  4445:
  4446:
  4447:         strcpy(value, "abcdefghijklmnopqrstuvwxyz");
  4448:         temp = value;
  4449:
->4450:         printf ("\n value = %s", value);
  4451:         printf ("\n temp  = %s", temp);
  4452:
  4453:         temp2 = malloc(512 + 1);
  4454:         memset(temp2, 0, 512 + 1);
  4455:
  4456:         printf ("\n temp2 = %s", temp2);
  4457:
  4458:         return;
─ OUT -output─────────────────────────────────────────────────────────────────────────────────
break at routine PROBLEM\main
break at routine PROBLEM\subroutine
stepped to PROBLEM\subroutine\%LINE 4438+11
stepped to PROBLEM\subroutine\%LINE 4447
stepped to PROBLEM\subroutine\%LINE 4448
stepped to PROBLEM\subroutine\%LINE 4450
PROBLEM\subroutine\value:       "abcdefghijklmnopqrstuvwxyz"
PROBLEM\subroutine\temp:        8848580204684932775
──────────────────────────────────────────────────────────────────────────────────────
─ PROMPT -error-program-prompt─────────────────────────────────────────────────────────────────────────────────
DBG> ex value
DBG> ex temp
DBG> ex *temp
%DEBUG-E-NOTRAZERO, Unable to find a trailing zero for ASCIZ object at address 7ACC78D07ACC76A7
DBG>
─────────────────────────────────────────────────────────────────────────────────────

Value has the string we expect.
temp S/B pointing at value - and from the output without debug, we know it is.
The debugger is totally lost.

We know the memory allocated to temp2 is set to all zeros (NULL) and we get the same error about being unable to find a trailing zero...

makes it difficult, when even local variables are not able to be examined, to do debugging....

[imiller]

A C compiler, hurrah!

[marxch]

Are there any news regarding the new compilers?

[jreagan]

Soon. I built/tested a Pascal compiler on my VirtualBox today. I installed the new C compiler on my system too. Waiting on the matching Fortran.

[tlovern]

look forward to them, will test them as soon as they drop!

thanks!

[jreagan]

The new C, Fortran, Pascal should be available now.

[tlovern]

Hmm, I'm not seeing any improvement....

VSI C x86-64 X7.4-843 (GEM 50XB9) on OpenVMS x86_64 V9.2-1

Code: Select all

 35813:                         // -------------------------------------------------------
 35814:
 35815:                         memset(newValue, 0, 133);
 35816:
 35817:                         if ((strlen(userInput) != 0) || (keyboard->cmd_value == CMD_CLR))
 35818:                                 status = rtl_format_field_storage(keyboard, userInput, var, newValue);
 35819:
->5820:                         if (status != 0)
 35821:                                 break;
 35822:
 35823:                         // -------------------------------------------------------
 35824:                         // load data into physical location
 35825:                         // -------------------------------------------------------
 35826:
 35827:                         if ((strlen(userInput) != 0) || (keyboard->cmd_value == CMD_CLR))
 35828:                                 status = rtl_load_phyfld(keyboard, var, newValue);
 35829:
 35830:                         if (status != 0)
 35831:                                 break;
 35832:
 35833:                         // -------------------------------------------------------
 35834:                         // format data for display
 35835:                         // -------------------------------------------------------
─ OUT -output─────────────────────────────────────────────────────────────────────────────────
stepped to RTL_INPUT_FIELD\rtl_input_field\%LINE 35771
stepped to RTL_INPUT_FIELD\rtl_input_field\%LINE 35772+7
stepped to RTL_INPUT_FIELD\rtl_input_field\%LINE 35815
stepped to RTL_INPUT_FIELD\rtl_input_field\%LINE 35817
stepped to RTL_INPUT_FIELD\rtl_input_field\%LINE 35808+2
stepped to RTL_INPUT_FIELD\rtl_input_field\%LINE 35817
stepped to RTL_INPUT_FIELD\rtl_input_field\%LINE 35818
stepped to RTL_INPUT_FIELD\rtl_input_field\%LINE 35820
──────────────────────────────────────────────────────────────────────────────────────
─ PROMPT -error-program-prompt─────────────────────────────────────────────────────────────────────────────────
DBG> ex var
%DEBUG-E-NOSYMBOL, symbol 'var' is not in the symbol table
DBG> ex newValue
%DEBUG-W-UNALLOCATED, 'newValue' is not allocated in memory (optimized away)
DBG>
──────────────────────────────────────────────────────────────────────────────────────

[jreagan]

Sorry about that. We'll have a look.

Added in 10 minutes 17 seconds:
We might want to see the larger code in a support ticket to make sure that we get it right this time.

[tlovern]

Let me see what I can package up - that code has a lot of modules baked into it....

This is how we get it right - find a problem, isolate it and move on to the next one.

[tlovern]

Tracked it down, it appears to be working correctly. I needed to re-build a library and that seemed to fix it, along with changing the order in the option file for the linker.

rebuilding everything (successfully) seems to have fixed the problem. I'll continue my testing.

Thanks.