All,

The RETSTACK() function returns a list of procedures on the OI return stack. However, it does not return the line number at which execution branched from the procedure. There once was a third-party debugger add-on for AREV, called REVEAL, that provided a function REVEALGETRETURNSTACK() which returned both the program names and the line numbers. Does anyone know of a way to get the same information from OENGINE?

Sincerely,

Peter Walter

pwalter@itlsys.com

To the best of my knowledge OI / Oengine work quite differently than AREV .. AREV.EXE was executing on the desktop in a singhe-threaded mode while OE doesn't .. especially now that it's a DLL.

Don Miller

C3 Inc.

Well Don the info is available - the debugger uses it after all! But the info is not exposed as standard.

The Sprezzatura Group

World Leaders in all Things RevSoft

Having that information would be very useful in error situations. If clients with crashing apps can call in with all details about return stack and line numbers bugs would be much easier to find.

Perhaps Revelation Software UK could have a look at the problem?

- Oystein -

Having that information would be very useful in error situations. If clients with crashing apps can call in with all details about return stack and line numbers bugs would be much easier to find.

Just deploy your apps with source code and debug variables and this problem will go away!

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don,

Please explain. Do you say my clients should run with the Debugger activated? And I should sprinkle my code with "else debug" stuff?

- Oystein -

Oystein,

I'm obviously joking but if you distributed source code and the debug tables then when your programs crashed your end users would be able to see everything you do as a developer through the debugger.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Well .. FWIW, I do deploy the source and symbol tables in a Run TIme and do something like the following:

IF SOMEBIZARRE CONDITION THEN

• press the F10 Key times

 DEBUG

• You got here with an error

• Call C3 Inc. at 800-243-9583

 variables that got us here

• Press the F5 key or follow directions from C3I

END

So .. the line #'s and vars are available under these conditions

Don M.

I recently returned to programming in OI after a long hiatus. My application, being converted from AREV, uses hundreds of programs and windows, and it would be impossible to support properly without such advanced information. In my AREV code, whenever a critical error occured that would normally send the program into the debugger, or whenever the currently executing program detected a serious logical / physical error, custom code dumped stack trace information, AREV environment information, and OS system environment information to a table, emailed everything off to a support site for analysis, and attempted to gracefully recover from the error if possible without terminating AREV. In conjunction with an automated updating feature, this allows very fast turnaround times for fixing an application with a very high change rate. All I am trying to do is get similar functionality from OI so I can finally migrate from AREV. But, if gurus like Sprezz do not know how to easily do something like this, then I will have to pause the code conversion (again) and spend a few weeks mucking with the internals of OENGINE until I figure it out. RETSTACK() is simply a pointer to a function call within OENGINE, and I am sure the information is available because the debugger knows; I do not see the harm in releasing it to developers. Aaron? can you help?

Don,

I'll have to clean up my comments then. Remove swear words and comments to myself about ugly code that ought to be redone…

What if we could have a different version of the Debugger for runtime systems? One that presents the stack and line number and not much more?

- Oystein -

Oystein ..

FWIW, I think that would be more of a pain than it's worth. If you can't see the contents of local variables and system variables too, then the line number would only provide a little bit of info. For example, the following is included in all reports:

STATUS=0

CALL SET_STATUS(STATUS)

RLIST …

or

OR_VIEW

IF GET_STATUS(STATUS) THEN DEBUG

STATUS can get set for a number of reasons but all of them are fatal. However, not all of them are in the code. STATUS is a very useful variable at this point as well as global vars and the call stack.

Don M.

Don,

If you can't see the contents of local variables and system variables too, then the line number would only provide a little bit of info. …

Well, then I simply decide that this Runtime Debugger should also

- dump the content of all variables and properties to a text file, email it to the developer, or whatever

- do a Get_Status(Status) and likewise dump Status

- dispense a couple of Prozacs for the client

- etc

- etc.

And let's have a Pro version that automatically ships a crate of beer to the developer.

- Oystein -

Oystein et al:

We're talking about such beasts internally (minus the beer delivery). These type of 'Blue Sky' ideas are exciting and make us glad that these are the types of issues we need to deal with now- a far cry from the state of the software a year or so ago.

Thanks!

Revelation,

We love you.

- Oystein -

This is just for ARev, since I'm not 100% sure exactly how OE handles all this stuff, but I don't expect it to be all that different.

To the best of my recollection, the syscom variable used is only updated from within the debugger. Remember, there are no true line counters in R/BASIC. Line counters are only updated when the LINEMARK statement is encountered. By default, the compiler places this after each statement, but this can be disabled. So, all a linemark is is a count of how many linemark updates (or counters) are encounter up to this point in the program string.

That's why you can't goto a specific line number in the code, but jump to a label, which is an offset position into the object code.

As I recall, each iteration through the debugger calls this opcode, whereby the current object code is parsed to the current point, counting the linemarks in the object code and returns back the current line to the debugger programs. This code is only called when the system is in debug mode.

I suppose you could find a way to force the system into debug mode, by shelling debugger, then only loading the actually debugger program when additional debug criteria are met, but that's really the only way as far as I know. That's probably what the replacement debuggers do.

So, to sum up, the debugger only knows what the line number is because after each program statement, the engine goes and counts the number of link mark indicators up to the currently executing byte.

OpenEngine may work in a different way, but I would not expect that it does.

The Sprezzatura Group

World Leaders in all Things RevSoft

Sprezz,

Thanks for the comments. However, I do not agree entirely. I understand completely that the actual line numbers are not stored within the object code, that the line number reported by the debugger is acually a LINEMARK count. However, to the best of my recollection, the AREV engine "knows" how many linemarks has been encountered, and associates the linemark count with the byte offsets of each opcode within the object code. This is easily demonstrated by pressing Ctrl-Break within any AREV executing program compiled with linemarks; the debugger reports the line number, even within a looping construct, although there may not be any actual DEBUG statements in the code. Whenever a called subroutine, function, or the debugger is loaded, the runtime engine stores the return information on the return stack (obviously, as it has to know how to return to the calling program). Some years ago, I investigated how the AREV engine stores the return stack, and located the (undocumented) SYSCOM variables involved; however, I never followed up with creating extraction code myself because there was already a third-party tool available for that purpose which also provided advanced debugging capabilities. The third-party tool did not require that the debugger be called. If anyone knows of a third-party tool for OI that replicates this functionality, please let me know. If one is not available, and others express an interest is also having such a tool, then I may work on one in my spare time.

My proposed OI application is not static, but has a very high change rate requiring windows and programs to be created or modified on a daily basis to support the client requirements. The application has to be high-availability; program faults, debugger breaks, sustained record locks, and other abnormal conditions (such as OENGINE terminating unexpectedly) need to be prevented, or identified and corrected quickly so as not to tie up hundreds of users. The client switched to AREV from Oracle precisely because Oracle could not deliver the necessary low turnaround times for changes on a running system, measured in minutes or hours, not weeks or months. That was the major selling point of the AREV application, and the client would like to see the same functionality in a proposed OI version. The capability to determine, in an automated fashion, how, why and where an application component failed, and to immediately inform the technical support staff, is critical to the change management features.

In the interim, I will simply put this one down as yet another sophisticated AREV capability not currently available in OI, and I will develop a workaround for now.

Guys, thanks for all the input. I will quietly return to the AREV programmer's retirement home now.

Sincerely,

Peter Walter

pwalter@itlsys.com

Peter,

I think you missed the point of the message. When the debugger is invoked, the opcode interpreter goes into debug mode. When the program is in debug mode, an opcode is called which counts the number of linemarks up to the current bit in the executing routine. The number is not stored or generated at all during processing. It is only calculated, at each opcode call, when the interpreter is in debug mode. The previous value is not resused, and the counter is recalculated at each call.

When the break key is pressed and the debugger is loaded, the program does not remember what line number you are at. It remembers what offset position from the start of the program it is at. Otherwise, input.char would always restart at line 1.

It's not a matter of checking return stacks or program stacks or even syscom stacks. The value does not exist anywhere in memory. To do what you wish you would have to emulate the opcode, call the opcode in question, or force the interpreter to enter debug mode.

The program you are referring to must have forced the program to enter debug mode and acted as replacement debugger. Then, since it would be a shell to RTP25, it would be in a position to read the line number that was derived and calculated milliseconds before it's execution.

Once RTP25 is shelled, since you know how to map memory and write 8086 assember you could then pull out the syscom variable that the line counter is returned in.

However, this is completely different than just adding a @LINE.COUNT variable to match the syscom definitions for the other @variables. Without recoding the entire workings of the engine, there would have to be a flag to generate this value at each opcode call.

It has nothing to do with sophistaction of ARev over OI. Since the opcode interpreter interprets RevG code, one could assume OE uses the same structure and interpreter logic as ARev. For OI, it would probably be easier since C++ lobrary and memory snoopers are far easier to use than ASM ones. The only hard part is forcing the OE to always run with the debug flag set. Of course, when this happens, your REVDEBUG.DLL replacement will always be called.

The only reason I'm so sure about all of this, and am convinced of it's impracticallity, is I wanted to implement @LINE.COUNT and @PRINT.LINE.COUNT (which would contain the current line number the system is printing at). After spending days in the ASM code and compiling numerous test EXEs, I found no other way to do this than call the linecounter opcode after each executing opcode.

The Sprezzatura Group

World Leaders in all Things RevSoft

And I vote for the beer and a cane! Still, grand to see someone still pays attention.

Don

Sprezz,

I understood your message very well. You misunderstood what I am looking for. I am not concerned with getting the current line number within the program currently executing; I need the line numbers in the program return stack at the point the previous program(s) branched. RETSTACK() returns the programs, but does not return the branch points.

I am quite familiar with the internals of AREV, having worked with REV since REV Release E. To do what I want to do, it is not necessary to shell RTP25 or set any of the debug flags in the interpreter. Since I know that obtaining this information from AREV is possible, and that the internals of OI are somewhat similar to AREV, at least where opcode execution is concerned, it is likely that it is possible to do the same for OI. So, today I spent a few minutes on this issue, examining SYSCOM in AREV. In brief, to get the return stack programs and branch line numbers, you need to access SC_CALLSTACK and SC_PROGSTACKIDX. The line numbers can be determined simply by counting the linemarks in the object code to the position where the execution of each program branched. I think I have now figured out the logic I need to get the job done in OI, and will now write my own custom code to do it. I hope RTI will support this feature natively in future releases.

Did anyone ever use Reveal by Chris Herbert?

Jim,

Yes. I have lost track of Chris. Do you have any contact information?

No I don't, we still use his AREV debug program however.

View this thread on the forum...