TURBO'd app that hangs the QL on termination...

Anything QL Software or Programming Related.
stevepoole
Super Gold Card
Posts: 712
Joined: Mon Nov 24, 2014 2:03 pm

Re: TURBO'd app that hangs the QL on termination...

Post by stevepoole »

Hi again,

On reading through the Turbo manual for possible causes : (3.2.2.5 etc)

With what parameters do you OPEN your CON device ? Do you append a type-ahead buffer size ?

Do you use KEYROW ? Multitasking with keyrow can swamp the second processor.... So Try PAUSE 25 before STOP. ( This often works for me).

Instead of keyrow, try PEEKing the key queue, it is much faster !

SBASIC #0 seems to be getting clobbered, which could be via swamping the key queue ?

Steve.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: TURBO'd app that hangs the QL on termination...

Post by martyn_hill »

Hi Steve

Interesting point you raise.

I actually resorted to directly peeking SYS_LCHR rather than using the CON look-ahead buffer - principally because I didn't want the overhead of enabling/disabling the cursor around each invocation of INKEY$. I then use a single KEYROW call to effectively clear the look-ahead buffer (as I understand it), before returning the PEEKed value from sys_lchr. This 'GetKey%' function is called at least once for each cycle round the main loop - so about 8-10 times a second, when compiled (only once per sec, when interpreted!)

As multi-masking wasn't a priority in parallel with this 'real-time' app, this seemed a safe enough approach.

I already have an (effective) PAUSE before the final STOP - I use one of the Timers for my pausing to ensure that any pending keypresses don't prematurely terminate the timeout.

The fact that running the very same code directly under the interpreter works without crashing at termination does point to either Turbo's closing code clashing with my 'environment', or else one of the key differences between interpreted/compiled jobs.

I'm prompted for some more little tests...


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: TURBO'd app that hangs the QL on termination...

Post by tofro »

The main difference between a STOP in a compiled program and the same thing under the interpreter is that the former will hand all memory that belonged to the job back to QDOS for re-use, while the latter will not (as you don't terminate the SuperBASIC job, so all memory owned by your program will at least stay valid).

Some things to try out:
  • Try a CLEAR and CLOSE or NEW under the interpreter after the program has ended - In case you have handed back some memory to QDOS that is still owned by "you" (your job), this should crash as well, because it will now do pretty much the same your compiled job does when terminating (cleaning up the memory you have allocated). The same thing happens when you re-RUN the program.
  • Do a CLEAR and CLOSE in the compiled job before the STOP - In case it crashes there rather than the STOP, you'd know there's memory corrupted by the job. I would then closely examine any DIMs and re-DIMS in the program.
  • Try and compile the same program with QLiberator to exterminate any possible Turbo-related problems (Not that I'd know of any). Depending on what exactly you do with Turbo, this is maybe an easy task. Not sure what to recommend in case this worked, though ;)
Do all this under the surveillance of SYSMON - Otherwise you might possibly miss heap corruption problems until much later than they actually occurred.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: TURBO'd app that hangs the QL on termination...

Post by martyn_hill »

Thanks Tobias

That is a very interesting approach. In the meantime, I've since tested running a small SB program alongside - that simply display DATE$ in #1 each second and running the compiled app with EX instead of EW.

At the STOP (when I have just BEEPed as well), the clock stops running in the SB #1 window - indicating that its not just that Job 0's #0 is hammered (which would prevent any further input in to Job 0) - but more globally - such as memory allocation, as you indicate.

Yes, I can easily try explicitly releasing memory under the interpreter, and also earlier in the compiled job to see if I can provoke the behaviour before STOP...


stevepoole
Super Gold Card
Posts: 712
Joined: Mon Nov 24, 2014 2:03 pm

Re: TURBO'd app that hangs the QL on termination...

Post by stevepoole »

Martyn,

Where is the program called from ?

If it is called from within code, ( eg boot ), what are the following statements ?

Steve.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: TURBO'd app that hangs the QL on termination...

Post by martyn_hill »

Hi Steve

Yes, called from my simple Boot program, thus:

IF key$=<something> THEN
CLS #0
T_ON
EW <path_to_exe>;"<exe_params_for_OPTION_CMD$>"
T_OFF
ELSE
...
END IF
STOP

The T_ON/T_OFF were moved from within the app to the Boot wrapper a few versions ago - and didn't appear to make any difference.

EX produces the same effect, but obviously allows CTRL-C to re-enter Job 0 and run that side-by-side 'clock' diagnostic - which freezes when the exe returns (if it really returns...)

I've since placed an explicit CLEAR slightly earlier in the close-down procedure. The program appears to return from the CLEAR successfully, to go on to execute a 2-second PAUSE followed by a further debug PRINT statement, before then bringing-down the QL - again at the very last instruction: STOP.

Now, here's a very curious thing that may or may not be relevant: After running again the same version as above, but under the interpreter, typing CLEAR returned (slowly) but as expected.

Upon typing NEW, however, whilst the QL didn't hang, it did proceed to re-draw all my CON_ windows that were supposedly CLOSEd earlier in the close-down phase in a 'CloseWindows' routine. The SB channels no longer appear to remain open when NEW returns, but the display now shows all those empty windows, along with any borders that had been defined (about 10 of them.)

The code logic definitely invokes the CloseWindows routine - no idea why they persist somewhere nor whether this is also true when executing the compiled version. Bizarre.

Thinking LNG again... I had disabled LNG in previous attempts without change of behaviour, but I'll retry again.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: TURBO'd app that hangs the QL on termination...

Post by martyn_hill »

So, disabling LNG, got rid of the 'ghost' CON_ displays when run under the interpreter, but the compiled program still fails to drop back to SB after STOP.

Can't put it off any-longer, need to employ the help of a debugger... :-)


stevepoole
Super Gold Card
Posts: 712
Joined: Mon Nov 24, 2014 2:03 pm

Re: TURBO'd app that hangs the QL on termination...

Post by stevepoole »

Hi Martyn,

Are you closing successive windows in one CON_ or a sequence of CON_ channels ?

Does the close_windows routine use explicit integers, or variables to close channels ?

Using variables with CON can lead to problems I have read in documentation... (vars are often floats, and need to be initialised in QDOS).

Hope you get to the bottom of this problem.

Regards,
Steve.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: TURBO'd app that hangs the QL on termination...

Post by martyn_hill »

Hi Steve

There are 11 independent CON_ channels, the channel # (and other details) held in a 2D integer array (wDefs%).

The channel #'s are acquired from FOPEN('CON_') and stored in the first index (0) of the array for each window definition (x & y position and dimensions, paper, ink - all read from DATA statements.)

So, when I close them, I use a FOR loop:

FOR w%=winMain% TO winTLights% : CLOSE #wDefs%(w%,0)

(winMain% and winTLights% are the first and last indices, defined previously.)

:-)


RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: TURBO'd app that hangs the QL on termination...

Post by RWAP »

I have sat reading this thread with a mixture of interest and amusement - as similar issues besieged some of my own Turbo programs.

Generally, the problem tends to be down to the machine code toolkits you are using in the Turbo'd program - normally corrupting the stack or similar.

In my own case after some frustration, it invariably ended up being that I had not allocated enough memory for the toolkits (either in Basic or in the way they were linked into the compiled Turbo task). In other instances it was just a bug in the machine code extension which was corrupting the return stack.


Post Reply