Page 2 of 2

More debugger woes...

Posted: Wed Oct 04, 2023 1:46 pm
by 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....

Re: More debugger woes...

Posted: Mon Oct 30, 2023 5:20 am
by imiller
A C compiler, hurrah! 8-)

Re: More debugger woes...

Posted: Thu Nov 09, 2023 2:12 am
by marxch
Are there any news regarding the new compilers?

Re: More debugger woes...

Posted: Sun Nov 12, 2023 10:26 pm
by 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.

Re: More debugger woes...

Posted: Mon Nov 13, 2023 12:07 pm
by tlovern
look forward to them, will test them as soon as they drop!

thanks!

Re: More debugger woes...

Posted: Thu Nov 16, 2023 9:04 am
by jreagan
The new C, Fortran, Pascal should be available now.

Re: More debugger woes...

Posted: Fri Nov 17, 2023 12:48 pm
by 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>
──────────────────────────────────────────────────────────────────────────────────────


Re: More debugger woes...

Posted: Fri Nov 17, 2023 12:55 pm
by 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.

Re: More debugger woes...

Posted: Fri Nov 17, 2023 2:31 pm
by 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.

Re: More debugger woes...

Posted: Mon Nov 20, 2023 1:03 pm
by 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.