DEBUG BASIC on X86

[cct]

I am getting a BASIC program failing with:

Code: Select all

%SYSTEM-F-ACCVIO, access violation, reason mask=15, virtual address=FFFFFFFF800♦
␍␊  Improperly handled condition, image exit forced by last chance handler.
    Signal arguments:   Number = 0000000000000005
                        Name   = 000000000000000C
                                 0000000000000015
                                 FFFFFFFF80004E70
                                 000000007AC31950
                                 000000000000001B
    Register dump:
    RAX = FFFFFFFF80004E70  RDI = 000000007AC31838  RSI = 00000000800061A0
    RDX = 000000007AC31808  RCX = 0000000000000001  R8  = 000000007AC31F18
    R9  = 000000007AC313B0  RBX = 000000007AC31630  RBP = 000000007AC31950
    R10 = 000000007AC31F20  R11 = 000000007AC313A0  R12 = 000000007AC31570
    R13 = 000000007AC31608  R14 = 000000007AC31778  R15 = 000000007AC31570
    RIP = 000000007AC31950  RSP = 000000007AC31570  SS  = 000000000000001B
  SPICDEV      job terminated at 19-APR-2024 19:22:46.84

So I tried to debug it, and practically every step, I get message:

%DEBUG-I-EXPMEMPOOL, expanding debugger memory pool

When I got tired, I just said GO, which it did, but returned the following:

Code: Select all

%DEBUG-E-ERROR, debugger error or session corruption

Logging enabled to file: DBGERR.LOG

If you wish to log a Debug problem report please include:

     o This file.
     o The operating system version number.
     o The system type or types if using Client/Server mode.
     o The program being debugged, both source and image.
     o The last, if not all, debug commands entered.
     o Any other information which you think would be helpful.

Debugger Version: OpenVMS x86-64 Debug64 Version V9.2-009

 module name    routine name     line           rel PC           abs PC

Due to this internal error this debug session may be unreliable.

The DBGERR.LOG file only contained:

Logging enabled to file: DBGERR.LOG

This is VMS9.2 patched with VMS922X_PCSI V1.0 and VMS922X_UPDATE V1.0
VSI X86VMS BASIC X1.8-5

Any thoughts?

[arne_v]

There are numerous reports about problems with debugger on VMS x86-64.

I guess the options are:
1) wait for them to be fixed
2) print statements

Added in 2 minutes 38 seconds:
print statments would mean one of:
A) %if ... print ... %end %if
B) creating your own logging framework for VMS Basic

[cct]

Not a very good description, but the debugger under BASIC seems completely F###-ed!

Also BASIC is not working well with real world code. Basically anything I run is dropping out with an access violation - if the debugger can be believed, at very innocent expressions

[arne_v]

And you are linking as:

$ link/seg=code=p0 ...

?

Added in 1 minute 1 second:
And you have done:

$ install replace sys$share:DEC$BASRTL/share=noaddress

?

[cct]

And you are linking as:

$ link/seg=code=p0 ...

?

Added in 1 minute 1 second:
And you have done:

$ install replace sys$share:DEC$BASRTL/share=noaddress

?

I have certainly done the latter - not sure as to the first. Will give it a try.

Now it gets stuck in a loop

Will investigate tomorrow

What a shame we didn't get any meaningful release notes

Thanks

[jreagan]

I haven't seen that BASIC issue before, so a bug report would be good.

For the debugger mempool, we fixed it, but it didn't make the deadline for the upcoming V9.2-2 update2. We're looking at a debugger eco after update2 is finished.

John

[cct]

I haven't seen that BASIC issue before, so a bug report would be good.

For the debugger mempool, we fixed it, but it didn't make the deadline for the upcoming V9.2-2 update2. We're looking at a debugger eco after update2 is finished.

John

The looping was my fault - corrected. Then I got caught with a strange run time error - Access Violation seemingly caused by RETURN without GOSUB. It wasn't - just referencing a variable out of scope in a local function. Corrected. Surprised the compiler didn't pick it up, but maybe it was in scope, but set to an invalid value.

I will try more routines tomorrow - just need to build a runtime environment.

I look forward to the debugger fix. Any chance of a field test LSE?

[roberbrooks]

> Any chance of a field test LSE?

Soon. I have one more annoying bug to sort out before it gets released.
It's obscure enough that I might consider releasing LSE "as-is" and release noting
the problem (a periodic access violation from the SHOW LANGUAGE command).

At least one engineer in VSI has been using LSE for several months with no complaints.

-- Rob