Page 28 of 30
Re: Q_Liberator malaise
Posted: Wed Jul 09, 2025 11:50 am
by BSJR
Artificer wrote: Mon Jul 07, 2025 5:05 pm
BSJR wrote:
Another test object could be SuQcess, where DBAS can not be ignored.
Thanks for reminding me about SuQcess, all 3 versions of this that I have work perfectly with copyback on indicating that the DBAS file is not an issue with
SRQview. SuQcess is a lovely program with it's GD2 window.
I'm glad you like them.
Thanks for testing this issue. SQRview is undergoing a big update at the moment so the problem with v1.02 may disappear in v1.03, or not, wait and see.
BSJR
Re: Q_Liberator malaise
Posted: Wed Jul 09, 2025 8:31 pm
by Artificer
I have attached the screen shot for QTrans debug2. As you can see the last report before it hangs is at line 18232.
The jobs menu shows that the channel to be opened at line 18240 has not been opened.
Could the Q_ERR_ ON keyword cause the qtrans to hang. If so it may explain why Q604F runtimes work for most programs as some/many
won't use the Qliberator error trapping key words.
Re: Q_Liberator malaise
Posted: Thu Jul 10, 2025 8:31 am
by Martin_Head
That gives me something to home in on. I don't know if you want to try to write a test program to try to replicate the problem on the Q60.
I might split that line to see if it's the Q_ERR_ON or the OPEN_IN that causes the problem, or maybe remove the Q_ERR_ON.
Re: Q_Liberator malaise
Posted: Thu Jul 10, 2025 8:53 am
by Artificer
I don't know if you want to try to write a test program to try to replicate the problem on the Q60.
I will modify one of my existing programs to use QLib error trapping and see what happens.
Might take me a few days as I am unfamiliar with the QLib error trapping system.
Cheers
Re: Q_Liberator malaise
Posted: Thu Jul 10, 2025 9:07 am
by RalfR
The procedure is relatively simple. Important: Q_ERR_ON and Q_ERR_OFF only work with MC procedures, not with functions.
The Q_Liberator manual contains some good examples.
Re: Q_Liberator malaise
Posted: Thu Jul 10, 2025 10:46 am
by dilwyn
Here's the code surrounding the error point simplified to a test function, without the Easyptr stuff. This should clarify what is happening line by line so we can see which keyword exactly is causing the issue.
Q_ERR_ON temporarily converts a procedure like OPEN_IN into a function (internally) so that the Q_ERR function can pick up an error code instead of the program just stopping with an error like a procedure call normally would. If there is no error, Q_ERR returns 0. If there is an error, Q_ERR returns a negative value equivalent to the corresponding QDOS error codes. I've kept the line numbers the same as the original where possible.
Issues to suggest:
1. The Q_ERR_ON command is being used in a FuNction, in case this is relevant.
2. The program, compiled and uncompiled, is over 64K. The line which is causing the problem seems to be about 65% through the program code. Probably just coincidence and very unlikely, but as I'd noticed it, I thought I'd mention it in case 64K is relevant, in case there's a word/long word length issue.
3. The View_A_File function as it stands in this curt down example will return either a negative error code such as -7 for Not Found (accompanied by a "grunt" BEEP in line `18260), or 0 if the OPEN_IN succeeds.
By adding a "breakpoint" before each line you should be able to pick up which keyword is causing the issue. If this program works and doesn't show the problem, there will be two issues to consider next:
1. program length - e.g. does it only happen over 64K.
2. Easyptr has somehow caused an issue, in which case diagnosis may be more difficult
Code: Select all
100 src$ = 'win1_' : file_name$ = 'random_doc'
12920 file_in_list = View_A_File(src$&file_name$,1)
12922 :
18060 DEF FN View_A_File (called$,lr%)
18070 LOCal a,actions,stat%,t$,num2,fer
18240 Q_ERR_ON 'open_in'
18245 OPEN_IN #3,called$
18250 fer = Q_ERR
18255 Q_ERR_OFF 'open_in'
18260 IF fer < 0 THEN BEEP 5e3,50 : RETurn fer
19480 RETurn 0 : REM success
19490 END DEFine View_A_File
Re: Q_Liberator malaise
Posted: Thu Jul 10, 2025 3:40 pm
by Martin_Head
I'm a bit short of time today. But I had a quick look at the QERR source code (attached)
I don't like the look of the code around L0186 in Q_ERR_ON, It sets bit 31 of a name table value entry (just like FOR was)
I think it's just trying to make the system think it's undefined, which should be -1. Or maybe it's just a flag for QLib use?
Which would fit using bit's 31,30, and 29 for QERR and FOR
Around L0110 it shifts the the value about to clear bit 31.
I don't have an idea for a fix yet, need to look a bit deeper.
Re: Q_Liberator malaise
Posted: Sat Jul 12, 2025 11:54 am
by Artificer
I have tweaked and compiled the snippet of code Dilwyn Jones supplied. The image shows the code and the outcome indicating that the program
hangs after Q_ERR_ON was set and when error trapping OPEN_IN.
Re: Q_Liberator malaise
Posted: Sat Jul 12, 2025 1:01 pm
by Mark Swift
Hi,
It's likely that the data cache will need to be flushed out to memory after this routine; before it can be executed as code.
Code: Select all
; Make 28 copies of this code in allocated buffer
L014E clr.l (a0)+
move.l #$207AFFFA,(a0)+ ;movea.l $01FFFC(pc),a0
move.l #$4E903D40,(a0)+ ;jsr (a0)
move.l #$00C27000,(a0)+ ;move.w d0,lv_qerno(a6)
move.w #$4E75,(a0)+ ;moveq #$00,d0
;rts
dbf d1,L014E ;loop
Thanks
Re: Q_Liberator malaise
Posted: Sat Jul 12, 2025 3:07 pm
by pjw
Artificer wrote: Sat Jul 12, 2025 11:54 am
QERRON.JPG
I have tweaked and compiled the snippet of code Dilwyn Jones supplied. The image shows the code and the outcome indicating that the program
hangs after Q_ERR_ON was set and when error trapping OPEN_IN.
Q_ERR_xxx figures largely in the Qlib compiler itself..