Skip to main content

I am stepping through code and to avoid long subroutine calls, I do a  "BLnnnn"  in the BASIC Debugger where nnnn is a line after the subroutine call I want to 'blip through' -- more often than not now, the BL command is met with a minidump:

I have altered the code a little to avoid anything proprietary -- but this is the gist... I did not want to step into the subroutine at line 1031.
SO ... I reasonably put in BL1032 which should catch me right after the routine comes back:
But instead.....
.L
[1024]        SOMETHING<2>    = COMPANY.NO:@VM:INVOICE.NO
[1025]        SOMETHING<2,-1> = INTERNAL.USER.ID:@VM:"":@VM:"1"
[1026]        SOMETHING<8> = BATCH.NO ; SOMETHING<9> = "POST"
(1027)        IF DEBUG.FLAG THEN
[1028]          IF ( DO.A.DEBUG ) THEN SOMETHING<1,-1> = "$VDEBUG"
[1029]          PRINT "Calling routine to DETERMINE.OUTPUT.DEVICE ..."
[1030]        END   
[1031]        CALL DETERMINE.THE.DEVICE(REPORT.NAME, COMPANY.NO,SOMETHING)
[1032]        IF ( SOMETHING<11> ) THEN
!BL1032
U2 exception handler...
Generating exception log file E:\\ud52\\minidump\\exception_8628_0426_112707.txt...
 
In E:\\UD52\\account\\bpfile\\_progname at line 1027 Unhandled Exception raised at address 0xDFC42ADD : Access violation.  Attempted to read from address 0xFFFFFFFF.
Exception file: E:\\ud52\\minidump\\exception_8628_0426_112707.txt
Min dump file: E:\\ud52\\minidump\\u2dump_8628_0426_112707.dmp
Logging process information...
Logging process time information...
Logging process memory information...
Generating dump file...
Logging UniBasic call stack...
Logging U2 Basic open files...
Logging expbuf usage info...
Logging SPC info...
Logging attached shared memory addresses...
Executing ipcstat utility...
Executing sms utility...

And this happens in LOTS of places -- why is the BASIC debugger doing this now, and is this new to this release?

I am having to resort to coding in "DEBUG" or PRINT xxx/ INPUT WAIT into the code, which just means I have to take it all out later.

AND it is not EVERY use of "BL" - just in some cases which I cannot identity the 'why' part -- sometimes it works, many times it MINIDUMPS.

Any thoughts welcome -- I don't know how to make this 'happen' in a way I can hand off in a support case to Rocket -- if there are thoughts there, glad to hear those as well.

I feel accomplished, as I have generated over a dozen MiniDumps in the last hour.  A new personal best.  :eyeroll:   :-)



------------------------------
David Wolverton
Independent
Sunset Programming Inc
Waltham MA US
------------------------------

I am stepping through code and to avoid long subroutine calls, I do a  "BLnnnn"  in the BASIC Debugger where nnnn is a line after the subroutine call I want to 'blip through' -- more often than not now, the BL command is met with a minidump:

I have altered the code a little to avoid anything proprietary -- but this is the gist... I did not want to step into the subroutine at line 1031.
SO ... I reasonably put in BL1032 which should catch me right after the routine comes back:
But instead.....
.L
[1024]        SOMETHING<2>    = COMPANY.NO:@VM:INVOICE.NO
[1025]        SOMETHING<2,-1> = INTERNAL.USER.ID:@VM:"":@VM:"1"
[1026]        SOMETHING<8> = BATCH.NO ; SOMETHING<9> = "POST"
(1027)        IF DEBUG.FLAG THEN
[1028]          IF ( DO.A.DEBUG ) THEN SOMETHING<1,-1> = "$VDEBUG"
[1029]          PRINT "Calling routine to DETERMINE.OUTPUT.DEVICE ..."
[1030]        END   
[1031]        CALL DETERMINE.THE.DEVICE(REPORT.NAME, COMPANY.NO,SOMETHING)
[1032]        IF ( SOMETHING<11> ) THEN
!BL1032
U2 exception handler...
Generating exception log file E:\\ud52\\minidump\\exception_8628_0426_112707.txt...
 
In E:\\UD52\\account\\bpfile\\_progname at line 1027 Unhandled Exception raised at address 0xDFC42ADD : Access violation.  Attempted to read from address 0xFFFFFFFF.
Exception file: E:\\ud52\\minidump\\exception_8628_0426_112707.txt
Min dump file: E:\\ud52\\minidump\\u2dump_8628_0426_112707.dmp
Logging process information...
Logging process time information...
Logging process memory information...
Generating dump file...
Logging UniBasic call stack...
Logging U2 Basic open files...
Logging expbuf usage info...
Logging SPC info...
Logging attached shared memory addresses...
Executing ipcstat utility...
Executing sms utility...

And this happens in LOTS of places -- why is the BASIC debugger doing this now, and is this new to this release?

I am having to resort to coding in "DEBUG" or PRINT xxx/ INPUT WAIT into the code, which just means I have to take it all out later.

AND it is not EVERY use of "BL" - just in some cases which I cannot identity the 'why' part -- sometimes it works, many times it MINIDUMPS.

Any thoughts welcome -- I don't know how to make this 'happen' in a way I can hand off in a support case to Rocket -- if there are thoughts there, glad to hear those as well.

I feel accomplished, as I have generated over a dozen MiniDumps in the last hour.  A new personal best.  :eyeroll:   :-)



------------------------------
David Wolverton
Independent
Sunset Programming Inc
Waltham MA US
------------------------------

David,

Just checking - is this 8.2.4.3003 - released March 2023?

While there is no indication it could be related, this is worth a quick check - fixed in 8.3.1 - released in Jan 2024 - later then the last 8,2,4 patch release:

UDT-16660

  • UniBasic. Starting with version 8.2, if a program was compiled with the -D option and had an INCLUDE reference to a hashed file, after the process exited, a '_BS<pid>' file in UDT Temp would remain. The '_BS<pid>' file is not created during the compile stage, only after the program is executed. This issue has been resolved.

Check if there are any '_BS' files in UDT Temp - and if so check their permissions are rw for your user or group  (as a matter of course) and remove them. Just speculating here as this is the only debug-related change in later releases I could see in the release notices and it's an easy check.

Otherwise - does it happen only if you run multiple debugs in the same UDT session sequentially and always works if run as the first debug in a UniData session? If so it might at least allow you to work past it in the short term.  

Regards

JJ



------------------------------
John Jenkins
Thame, Oxfordshire
------------------------------

I am stepping through code and to avoid long subroutine calls, I do a  "BLnnnn"  in the BASIC Debugger where nnnn is a line after the subroutine call I want to 'blip through' -- more often than not now, the BL command is met with a minidump:

I have altered the code a little to avoid anything proprietary -- but this is the gist... I did not want to step into the subroutine at line 1031.
SO ... I reasonably put in BL1032 which should catch me right after the routine comes back:
But instead.....
.L
[1024]        SOMETHING<2>    = COMPANY.NO:@VM:INVOICE.NO
[1025]        SOMETHING<2,-1> = INTERNAL.USER.ID:@VM:"":@VM:"1"
[1026]        SOMETHING<8> = BATCH.NO ; SOMETHING<9> = "POST"
(1027)        IF DEBUG.FLAG THEN
[1028]          IF ( DO.A.DEBUG ) THEN SOMETHING<1,-1> = "$VDEBUG"
[1029]          PRINT "Calling routine to DETERMINE.OUTPUT.DEVICE ..."
[1030]        END   
[1031]        CALL DETERMINE.THE.DEVICE(REPORT.NAME, COMPANY.NO,SOMETHING)
[1032]        IF ( SOMETHING<11> ) THEN
!BL1032
U2 exception handler...
Generating exception log file E:\\ud52\\minidump\\exception_8628_0426_112707.txt...
 
In E:\\UD52\\account\\bpfile\\_progname at line 1027 Unhandled Exception raised at address 0xDFC42ADD : Access violation.  Attempted to read from address 0xFFFFFFFF.
Exception file: E:\\ud52\\minidump\\exception_8628_0426_112707.txt
Min dump file: E:\\ud52\\minidump\\u2dump_8628_0426_112707.dmp
Logging process information...
Logging process time information...
Logging process memory information...
Generating dump file...
Logging UniBasic call stack...
Logging U2 Basic open files...
Logging expbuf usage info...
Logging SPC info...
Logging attached shared memory addresses...
Executing ipcstat utility...
Executing sms utility...

And this happens in LOTS of places -- why is the BASIC debugger doing this now, and is this new to this release?

I am having to resort to coding in "DEBUG" or PRINT xxx/ INPUT WAIT into the code, which just means I have to take it all out later.

AND it is not EVERY use of "BL" - just in some cases which I cannot identity the 'why' part -- sometimes it works, many times it MINIDUMPS.

Any thoughts welcome -- I don't know how to make this 'happen' in a way I can hand off in a support case to Rocket -- if there are thoughts there, glad to hear those as well.

I feel accomplished, as I have generated over a dozen MiniDumps in the last hour.  A new personal best.  :eyeroll:   :-)



------------------------------
David Wolverton
Independent
Sunset Programming Inc
Waltham MA US
------------------------------

Not that this is an answer to the minidump problem, but when I am debugging and want to "blip" through subroutine calls (which is often, since I don't have source for vendor supplied code), I use "N1 R" from the debugger, to "step over" a line of code every time ENTER is pressed.

The dump is definitely not right, but perhaps N1 R could be a workaround in the meantime?



------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------

Not that this is an answer to the minidump problem, but when I am debugging and want to "blip" through subroutine calls (which is often, since I don't have source for vendor supplied code), I use "N1 R" from the debugger, to "step over" a line of code every time ENTER is pressed.

The dump is definitely not right, but perhaps N1 R could be a workaround in the meantime?



------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------

Ian, is N1 R the same as E1 R or is there a difference?



------------------------------
Kevin King
President
Precision Solutions, Inc.
Longmont CO US
------------------------------

Ian, is N1 R the same as E1 R or is there a difference?



------------------------------
Kevin King
President
Precision Solutions, Inc.
Longmont CO US
------------------------------

Kevin, both execute the current line; the only difference is that "E" steps into subroutine calls (F11 in VS), but "N" steps over them (F10), which is super helpful when you don't have the source code for all subroutines and "V"iew source is on.  Using "E1 R", I end up in a subroutine, have to do V to turn off view source, OUT to return back to the main program, then V to turn view source back on.

The past few years I've been trying to get better at using the debugger, and get away from liberally sprinkling CRT statements all over my programs :-) . I do sometimes emulate log4j and have e.g. LOGLEVEL=3 at the top, and have print statements like "IF LOGLEVEL>1 THEN CRT \\BLAH BLAH\\", which lets me turn the dial on how much logging to have.

Really looking forward to having a visual debugger in the VSCode extension!



------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------

Kevin, both execute the current line; the only difference is that "E" steps into subroutine calls (F11 in VS), but "N" steps over them (F10), which is super helpful when you don't have the source code for all subroutines and "V"iew source is on.  Using "E1 R", I end up in a subroutine, have to do V to turn off view source, OUT to return back to the main program, then V to turn view source back on.

The past few years I've been trying to get better at using the debugger, and get away from liberally sprinkling CRT statements all over my programs :-) . I do sometimes emulate log4j and have e.g. LOGLEVEL=3 at the top, and have print statements like "IF LOGLEVEL>1 THEN CRT \\BLAH BLAH\\", which lets me turn the dial on how much logging to have.

Really looking forward to having a visual debugger in the VSCode extension!



------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------

Awesome, thanks Ian.



------------------------------
Kevin King
President
Precision Solutions, Inc.
------------------------------
Terms & ConditionsAccessibility statement