More debugger woes...

User avatar

Topic author
tlovern
Active Contributor
Posts: 40
Joined: Tue Jul 21, 2020 10:44 am
Reputation: 0
Status: Offline

More debugger woes...

Post by tlovern » Wed Oct 04, 2023 1:46 pm

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....


jreagan
VSI Expert
Master
Posts: 139
Joined: Tue Dec 01, 2020 8:40 am
Reputation: 0
Status: Offline

Re: More debugger woes...

Post by jreagan » Wed Oct 04, 2023 2:27 pm

What debugger are you using? V9.2-1 with update 1 is the latest. We have another one in the pipeline.

I'll grab your posted example and pass it along to right folks.

Added in 11 minutes 4 seconds:
The bug is with "how big is a pointer". LLVM DWARF thinks that all pointers on a 64-bit system must be 64-bits wide. We try to tell them 4 bytes, but they don't propagate that into the DWARF. [We're working on that]

If you look at temp's type in the debugger, you'll see

Code: Select all

 value = abcdefghijklmnopqrstuvwxyz
 temp  = abcdefghijklmnopqrstuvwxyz
break at BUG\subroutine\%LINE 4453
  4453:         printf ("\n temp2 = %s", temp2);
DBG> set rad hex
DBG> show symb/type temp
data BUG\subroutine\temp
    64-bit pointer to
        atomic type, byte integer, size: 1 byte
but it isn't a 64-bit pointer, it is a 32-bit pointer.
Examine temp and you'll see

Code: Select all

DBG> ev/addr temp
000000007AC5B8AC
DBG> ev/addr temp2
000000007AC5B8A8
DBG> exam/long temp
BUG\subroutine\temp:    7AC5B6A7
DBG> exam/long temp2
BUG\subroutine\temp2:   00128580
DBG> exam/asciz 7AC5B6A7
000000007AC5B6A7:       "abcdefghijklmnopqrstuvwxyz"
DBG> exam/quad 00128580
0000000000128580:       0000000000000000
Last edited by jreagan on Wed Oct 04, 2023 2:36 pm, edited 2 times in total.


marxch
Member
Posts: 6
Joined: Wed Nov 17, 2021 1:12 am
Reputation: 0
Status: Offline

Re: More debugger woes...

Post by marxch » Thu Oct 05, 2023 1:26 am

Is there a release date when the debugger update will be available?

User avatar

Topic author
tlovern
Active Contributor
Posts: 40
Joined: Tue Jul 21, 2020 10:44 am
Reputation: 0
Status: Offline

Re: More debugger woes...

Post by tlovern » Thu Oct 05, 2023 11:41 am

I figured it was a pointer issue, thanks for passing it along.

I appreciate the quick responses.

Added in 17 minutes 23 seconds:
it is not letting me install the latest debugger:
Performing product kit validation of signed kits ...
%PCSI-I-VSIVALPASSED, validation of NARNIA$DKA100:[USERS.1LOVERN.TMP]VSI-X86VMS-VMS92X_DEBUG-V0100--4.PCSI$COMPRESSED;1 succeeded

%PCSI-E-APPLYTOERR, maintenance product VSI X86VMS VMS92X_DEBUG V1.0 applies to a product that is not installed
-PCSI-E-APPLYTOPRD, prerequisite product is VSI X86VMS VMS V9.2
%PCSIUI-E-ABORT, operation terminated due to an unrecoverable error condition
$ sys
OpenVMS V9.2-1 on node NARNIA 5-OCT-2023 08:52:36.32 Uptime 0 00:24:36
Last edited by tlovern on Thu Oct 05, 2023 11:59 am, edited 1 time in total.

User avatar

mister.moderator
Site Admin
Active Contributor
Posts: 31
Joined: Thu Apr 27, 2023 11:14 am
Reputation: 0
Status: Offline

Re: More debugger woes...

Post by mister.moderator » Fri Oct 06, 2023 3:38 am

From John's earlier post:
What debugger are you using? V9.2-1 with update 1 is the latest.
The latest debugger is included in Update 1 for V9.2-1. You should download and install this kit: VMS921X_UPDATE-V0100

Sincerely,
Mister Moderator
VMS Forum Moderator
VMS Forum Administrator


jreagan
VSI Expert
Master
Posts: 139
Joined: Tue Dec 01, 2020 8:40 am
Reputation: 0
Status: Offline

Re: More debugger woes...

Post by jreagan » Sun Oct 08, 2023 5:46 pm

That older DEBUG update applied only to V9.2. It was an early pre-V9.2-1 debugger. Since V9.2 isn't support anymore, we should remove that update kit to avoid confusion

For V9.2-1 update 2 is being tested now.

The pointer size confusion is actually with the compiler not telling the size. Once we update the compiler, the update 1 (or upcoming update 2) debugger should be happy

User avatar

Topic author
tlovern
Active Contributor
Posts: 40
Joined: Tue Jul 21, 2020 10:44 am
Reputation: 0
Status: Offline

Re: More debugger woes...

Post by tlovern » Mon Oct 09, 2023 10:56 am

good to hear - you guys have been very fast with getting this stuff resolved - kudos!


jreagan
VSI Expert
Master
Posts: 139
Joined: Tue Dec 01, 2020 8:40 am
Reputation: 0
Status: Offline

Re: More debugger woes...

Post by jreagan » Mon Oct 09, 2023 3:06 pm

tlovern wrote:
Mon Oct 09, 2023 10:56 am
good to hear - you guys have been very fast with getting this stuff resolved - kudos!
Thanks. We have quite a bit on our plate so if we seem to forget something, feel free to nag here or with a support ticket.

User avatar

imiller
Master
Posts: 147
Joined: Fri Jun 28, 2019 8:45 am
Reputation: 0
Location: South Tyneside, UK
Status: Offline
Contact:

Re: More debugger woes...

Post by imiller » Fri Oct 20, 2023 7:33 am

I see V9.2-1 Update 2 is available. 8-)
Will there be a C compiler update too?
Ian Miller
[ personal opinion only. usual disclaimers apply. Do not taunt happy fun ball ].


jreagan
VSI Expert
Master
Posts: 139
Joined: Tue Dec 01, 2020 8:40 am
Reputation: 0
Status: Offline

Re: More debugger woes...

Post by jreagan » Sun Oct 29, 2023 7:54 pm

We're trying for a new C (and Pascal and Fortran) in the next few days

Post Reply