UniData 8.2.4 Dumping on use of BL in Debugger

Has anyone else experienced this?  

Since the move to UniData 8.2.4 Build 3003, I cannot use the "BL"  (Break at Line) in the UniBASIC Debugger without getting a mini dump for my troubles.

I am unclear if I've just gotten really unlucky, or if something is not working as expected in this build.

I have the team I work with opening a case, but wanted to see if this is something that is just my miserable luck, or if something is not quite right.

It pretty consistently tells me I have an 'Access violation.  Attempted to 'read from address 0xFFFFFFFF' 

I have the same problem.  Smaller programs seem to work, but the larger ones don't.

@David Green  @David Wolverton

There was an issue with the Debugger using BL and core/mini dumping, the issue was UDT-16438. This was fixed at 8.2.2.

I have tested our internal reproduction cases we had for the issue and they do not fail on the latest UniData release 8.2.4.3005, given that the tests we have for the fix our built into our automatic tests run on each release, I would not expect them to fail at 8.2.4.3003 as they would have been across that release as well.

I would like one of you to raise a support case with us, or provide a standalone reprdouction case via this thread so that I can look at here and see if the same thing happens on our machines.

For reference .... this is the results from testing UDT-16438 and UDT-16291 using our automated test (I performed all 9 tests and all 9 passed on AIX,Linux and Windows)

UDT-16438 'BL#' in Debugger reports error for globally cataloged programs

There are 3 programs in this test that need to be tested by each
catalog type. Choices are
Direct Catalog: DC.TEST1, DC.TEST2 or DC.TEST3
Local Catalog: LC.TEST1, LC.TEST2 or LC.TEST3
Global Catalog: GC.TEST1, GC.TEST2 or GC.TEST3

1. Execute one of the above programs
2. Type 'BL9' at the prompt
3. Type 'END' to escape out of the debugger

The proces core dumps or reports error after step 2.
Run 'CLEANUP' to cleanup the account

:GC.TEST2
'Global' Catalog Test, Type 'BL9' at Debugger Prompt
Type 'END' to exit Debugger

Compiling Unibasic: BP\\TEST2 in mode 'u'.
compilation finished

***DEBUGGER called at line 2 of program C:\\u2\\ud\\sys\\CTLG\\t\\TEST2
!BL9
!G
***Broke on command BL9
***DEBUGGER called at line 9 of program C:\\u2\\ud\\sys\\CTLG\\t\\TEST2
!END
:GC.TEST3
'Global' Catalog Test, Type 'BL9' at Debugger Prompt
Type 'END' to exit Debugger

Compiling Unibasic: BP\\TEST3 in mode 'u'.
compilation finished
***DEBUGGER called at line 3 of program C:\\u2\\ud\\sys\\CTLG\\t\\TEST3
!BL9
!G
***Broke on command BL9
***DEBUGGER called at line 9 of program C:\\u2\\ud\\sys\\CTLG\\t\\TEST3
!END
:

:!udt -revno
$uvuddb-ud82/hotfix/8.2.4.HF5@5f8b70bbc-20230917
:!type c:\\u2\\ud\\bin\\port.note
Platform         : INTEL
Operating System : Windows Server 2016
Porting Date     : Sun 09/17/2023 20:43:26.10
UniData Release  : Version 8.2.4, Build 3005
Ported by        : srcman
Compilers Used   : Visual Studio 2017
Source Revision  : 5f8b70b
UDT Configuration: Server, 64-bit(x64)

So we really need a simple cutdown reproduction case, so that we can see the problem here.

Thanks,

@David Green  @David Wolverton

There was an issue with the Debugger using BL and core/mini dumping, the issue was UDT-16438. This was fixed at 8.2.2.

I have tested our internal reproduction cases we had for the issue and they do not fail on the latest UniData release 8.2.4.3005, given that the tests we have for the fix our built into our automatic tests run on each release, I would not expect them to fail at 8.2.4.3003 as they would have been across that release as well.

I would like one of you to raise a support case with us, or provide a standalone reprdouction case via this thread so that I can look at here and see if the same thing happens on our machines.

For reference .... this is the results from testing UDT-16438 and UDT-16291 using our automated test (I performed all 9 tests and all 9 passed on AIX,Linux and Windows)

UDT-16438 'BL#' in Debugger reports error for globally cataloged programs

There are 3 programs in this test that need to be tested by each
catalog type. Choices are
Direct Catalog: DC.TEST1, DC.TEST2 or DC.TEST3
Local Catalog: LC.TEST1, LC.TEST2 or LC.TEST3
Global Catalog: GC.TEST1, GC.TEST2 or GC.TEST3

1. Execute one of the above programs
2. Type 'BL9' at the prompt
3. Type 'END' to escape out of the debugger

The proces core dumps or reports error after step 2.
Run 'CLEANUP' to cleanup the account

:GC.TEST2
'Global' Catalog Test, Type 'BL9' at Debugger Prompt
Type 'END' to exit Debugger

Compiling Unibasic: BP\\TEST2 in mode 'u'.
compilation finished

***DEBUGGER called at line 2 of program C:\\u2\\ud\\sys\\CTLG\\t\\TEST2
!BL9
!G
***Broke on command BL9
***DEBUGGER called at line 9 of program C:\\u2\\ud\\sys\\CTLG\\t\\TEST2
!END
:GC.TEST3
'Global' Catalog Test, Type 'BL9' at Debugger Prompt
Type 'END' to exit Debugger

Compiling Unibasic: BP\\TEST3 in mode 'u'.
compilation finished
***DEBUGGER called at line 3 of program C:\\u2\\ud\\sys\\CTLG\\t\\TEST3
!BL9
!G
***Broke on command BL9
***DEBUGGER called at line 9 of program C:\\u2\\ud\\sys\\CTLG\\t\\TEST3
!END
:

:!udt -revno
$uvuddb-ud82/hotfix/8.2.4.HF5@5f8b70bbc-20230917
:!type c:\\u2\\ud\\bin\\port.note
Platform         : INTEL
Operating System : Windows Server 2016
Porting Date     : Sun 09/17/2023 20:43:26.10
UniData Release  : Version 8.2.4, Build 3005
Ported by        : srcman
Compilers Used   : Visual Studio 2017
Source Revision  : 5f8b70b
UDT Configuration: Server, 64-bit(x64)

So we really need a simple cutdown reproduction case, so that we can see the problem here.

Thanks,

I have asked the client to send over the mini dumps -- the code is not that useful unless you have all the files in play -- and it's like 7 subroutines in to boot!  So hopefully the mini-dump will help.

@David Wolverton the mini-dump is not going to help in this case. We need a full reproduction case to look at the problem, as this not only will allow us to identify the problem, it gives us something to test against to make sure that we've fixed the problem.

Regards,