OpenROAD TraceWindow hangs

[Thomas_cim]

Hello,

we got the problem that the OpenROAD TraceWindow hangs, after closing every OpenROAD Application.

I've searched for the reason and found that the main thread of w4glrun.exe is haning in ... kernel32.sleep -> WTF ?

Tracing through a debugger it seems that the time of sleeping varies - I've found about 50 Seconds, and now its 29,109 Seconds ...

As a workaround I'll hide the Trace Window, and so the sleeping isn't visible anymore to our customer. (in fact, the w4glrun.exe process stays there while sleeping...)
But finding out what the problem really will be great.

I've attached the callstack.

Thanks your any ideas or help...

Thomas

PS: No, I don't think it has something to do with database sessions, and no, we don't issue a sleep 29.109 from an image - at least I think we don't do such strangely things...

PPS: OpenROAD Version

OR R 5.0/0804 (int.w32/00)
BUILDNO=4043
PATCHNO=14010

[Bodo]

Are you using portlets in some way?
Could it be that there are still some open (invisible) frames running?
Is this reproducible (always hanging) or only happening randomly?

[Thomas_cim]

Hello Bodo.

There is an open Ghotframe, and I thing two database connections are held, even after all frames have returned (apart from the ghostframe).

The curios thing about it, is that I can reproduce it in our system. Simply by using the Start-Image for this customer. The start-image is the only thing diverse from the standard. And in standard the problem does not occur.
(The start-image only has about 20 lines of effective code. Nothing special for this customer ...)

In fact we're using portlets, but they don't have been loaded when I close the app - I thing.

It is reproducable. The sleep time varies with every sleep. It's ever about 30 to 50 Seconds. And everytime the sleep time is some odd value...

Thomas

[Bodo]

So, how is the ghostframe being closed then?
The application won't exit (and cloe the tracce window) until the last running OpenROAD thread has been closed.
What does the ghostframe do? Is there a timer (CurFrame.SendUserEvent with delay)?
What's the starting component in the "start-image" actually doing?
I assume it's opening or calling some other frame (e.g. the starting component of the "standard").
So one difference might be that the parentframe of the called/opened frame is different.
How do you "close" the application? Are you using "EXIT" or "RETURN"? If you "RETURN", you might return to the starting component in "start-image" rather then really closing the application.
Could you run the image using the "Monimage" utility (w4gldev runimage iidebug.img) and monitor the threads of the application, i.e. when you do a "close" of the application.

[Thomas_cim]

In fact you're damn right - the ghostframe won't be closed.
I don't know who is responsible for that, but I will hang him ...

Can you explain to me why this doesn't make any problems on dozens of customers, and only this one does sleep so long ?

What does this sleep mean ? Is it some kind of timeout from OpenROAD, like: 'there's only an ghostframe left ... let's see if this ghostframe starts some new frames, and if not we're killing him after ~30 Seconds' ???

[Bodo]

I can only guess without the code or tracing.
As mentioned before, there could be several reasons for the delay, depending on how the ghostframe is eventually closing itself.
It could wait for an event, e.g. a database event, or it could could do some checks regularly (e.g. with a timer event).
So the differences in the delay could depend on how much time has already gone by since the last timer event was sent.
E.g. if there is a CurFrame.SendUserEvent(... delay=60) in a ghostsframes' userevent block (for the same event it sends), then when you do the "close" of your app 10 seconds after the last event has been sent, then it will take another 50 seconds until the event block is executed again.
You can also log the events (e.g. using "monimage").

[Thomas_cim]

I've found the main error - one event handling in the ghostframe was missing.
(Handling the terminate event ...)

The funny side is that there is no other way the ghostframe can close than 'on terminate' or 'on TERMINATEEVENT'.

So the questiong to me is: Why does it close ? In my opinion it should be running endless ...
Seems that this seems to be intentionally from OpenROAD. Simply calling a ghost frame which does nothing, does only run for about two Seconds ...

[Bodo]

The Terminate() is not the only way to end a ghostframe - there could also be a RETURN within the ghostframe's script or an EXIT in any script of the application.
It could also be closed implicitely!
This actually depends on how you open the ghostframe and what happens with the caller.
E.g. when the (empty) ghostframe is run from the workbench it's running forever (until you stop it). But if its opened from some other frame, the ghostframe gets closed whenever the parentframe is closed (dependent thread).
But when you do a "OPENFRAM ghost() WITH ParentFrame=NULL" you start an independent thread, so when you close the calling frame the ghost continues to run.
It's getting even more interesting when you do the OPENFRAME from within a local procedure of the caller:
If you do an "OPENFRAME ghost()" it will start the ghost as dependent thread, but the ghostframe will disappear when the local procedure returns/ends - as the ghost's parent is the local procedure.
If you do an "OPENFRAME ghost() WITH ParentFrame=CurFrame" it will start the ghost as dependent thread, the ghostframe will remain running until the calling frame closes.
If you do an "OPENFRAME ghost() WITH ParentFrame=NULL" it will start the ghost as independent thread, the ghostframe will remain running until it is terminated (or a RETURN is executed within the ghostframe or an EXIT anywhere).