Revealing the 4GL Callstack from a OpenROAD Process or Memory Dump

[HaraldF]

Hello,

finally I had enough time to write this little explanation how to see what OpenROAD is doing, when it seems that it is doing nothing :-)

The technique can also be used to analyze a Crashdump and see what OpenROAD has done at the time of generating the dump.

I know, this guide is VERY technical and most of us will never need it. But I've used it many times since finding out how this can be done.

Feel free to ask is something is unclear.

Harald

[HaraldF]

... and sorry for the crude formatting :-)

[jk]

Harald,

OpenROAD 6.2 will introduce a feature that might also be useful and a bit easier to use for most people. What you describe is black magic to most OpenROAD 4GL developers.

You technique stops the execution of OpenROAD and places you in the windbg debugger which allows you to view the 3GL call stack of the process that was interrupted. From here, you reverse engineer the OpenROAD runtime to deduce some information that you find useful.

What we are introducing in OpenROAD 6.2 is way to stop the 4GL program that started from OpenROAD Workbench. At the instant, you press a key to stop the 4GL we set an implicit breakpoint on the next 4GL statement so the program breaks in the 4GL debugger. The current executing 4GL statement must complete before the break happens. So if this is a long running query, the program will not stop until the query completes giving control back the 4GL interpreter.

Here is a link to the project:

Ingres OpenROAD Projects/Breaking out of tightloops - Ingres Community Wiki

Thanks,
-Joe

[Brigitte]

In addtion to Joes's answer
If we modify our internal structures or our code this will not work anymore and you will have to dig again in the internal.
Seems you are looking for a solution when running from an image outside the 4GL debugger? At the moment this is not possible but you can enter an enhancement request.

[HaraldF]

jk:
Thanks for the link - I've alread read it some time ago.

As I already said to Bodo, the OpenROAD Debugger is great, but my main problem with it, is that it doesn't help when some important OpenROAD Process simply stops working or runs endless.

So I'm missing the ability to trace through memory dumps and see what OpenROAD was doing while the dump has been generated.

It's not so easy to restart a OpenROAD Process in the Debugger which crashes after running 15 days and only under special circumstances.

My fellows keep on calling me when OpenROAD suddenly crashes, or when is runs endless. What shall I do then ?
1. Ship our Source Code to the customer.
2. Explain the OpenROAD Debugger to them.
3. Tell them to run all of their Client Programs under the Debugger.

This simple isn't possible :-)

And of course, my technique does not allow me to the see the 3GL Callstack, it allows me to see the 4GL Callstack. And I can see it from a crashdump which gets automaticly generated when any OpenROAD Process crashes, or from a running OpenROAD Process without interferencing it.

My main problem with this solution (I've alread built a program which automates the process of getting the 4GL Callstack from a running process) is that I can't see the calling parameters from the function or the local OpenROAD Variables of a Function.

Maybe I'll sometimes figure out how to get them.

Harald

[HaraldF]

Brigitte:

Yep, seeing what a running image is doing at the moment, or what it was doing at the time I clicked on 'generate dumpfile' in windows is exactly what I want.

The main problem we have is the anoying Message 'OpenROAD has stopped working'.
Our customers complain and we can do nothing more than insert Trace-Message here and there and tell them to keep the Trace-Window open and send us the tracefile when the crash happens again.
Sometimes we find the cause, sometimes we need to add more messages and play the game again and again.

Window has nice functions to generate a memory dump when any process crashes, but a memory dump of a crashed w4glrun isn't much helpful.
A memory dump of a C-Program points me straight to the crash, most of the time...

Harald

[jk]

Harald,

Thanks for the additional information. Yes, I agree that the senario you describe is a difficult one to address. Sometimes we have to resort to having our customers virtualize the machine that is showing the problems and ship it to us on a USB drive. Providing support to customers overtime is a very challenging task at times.

Thanks,
-Joe

[Thomas_cim]

Hi Harald,

it already helped me !

I had a w4glrun-Process which seemed to be stuck on a customer machine.
The Windows StackTrace showed that it was waiting for the Database.

Searching for the session I did find i very quick with inglogs, but the formatted Output of the DBMS-Server only showed me that the session is in the QEF, and Executing:

Query: Execute cduc_HisKopf

So it was a repeated query in the Class cduc_hiskopf.
Unfortunately cduc_hiskopf had 6000 lines of processed code and 25 repeated Querys in them.

I had no other idea to get to the failing query and so I tried to use Windbg and your manual.
It led me to the following stacktrace:

cduc_hiskopf.init() - Line 97

So I've found the bad query. Great work, thank you (again) :-)

Greetings,
Thomas