Re: [Ql-Users] Problem loading extensions

[Giorgio Garabello]

Ok, many thanks to all
Wolfgang i suggest you to explain this LRESPR's "limit" in the next version
of the SMSQ/E manual.

Giorgio

2017-02-23 6:19 GMT+01:00 Wolf :

> Hi,
>
> Even if never fixed, any chance you could share what you found as the
>> cause?
>>
>>
> Sure thing.
>
> This is how I see the error arises:
>
> First
> When you call the vector to initialise new keywords, the corresponding
> routine (at label "sb_inipr" in smsq_sbas_inipr_asm) allocates new memory
> for the new name table and much other information, shuffles the content of
> the old into the new, de-allocates the old and does quite some more
> shuffling/updating pointers.
>
> Second
> Whenever one is in a procedure, at the end of the procedure, you come to
> label "bo_return" (in the file smsq_sbas_iprocb_asm). Following the flow of
> that you will arrive at the following code:
>
> bor_lvlend
> cmp.l   d4,d5; bottom of locals yet?
> bgt.s   bor_lvloop   ; ... no
>
> move.l  rt_def(a6,a2.l),d0
> neg.l   d0   ; address of definition
>
> Unfortunately, the address D0 now points to (which is then copied into A4
> and used later) is now wrong. It still seems to point into some of the old
> memory that was deallocated.
>
> Now, with a bit of luck, the content of that memory hasn't been re-used
> between the call to sb_inipr and this point in the code, so that the
> program can continue normally. If not, you will most likely get
> into a heap error later:
>
> After the above code, just before you get to the loop at label
> "bor_fploop", the adress in A4 is used to get the number of parameters to
> treat. This is most likely wrong, so the loop counter for the loop is (in
> the case I observed) much bigger than what it should have been (note this
> could also have happened at label "bor_swloop" a bit earlier on). In the
> loop at label "bor_fploop" there most likely will be a cbra to label
> "bor_fpex" to clear the (local) variables used in the procedure via the
> subroutine at label "bor_clrval".
>
> This leads to label "sb_redat" (in smsq_sbas_aldat_asm) from there to
> "sad_rlx". This tries to release momory taken up by the (local) variables
> and, since one does that more often that is should have been, may lead to a
> heap error at label "sad_error":
> sad_error
> dc.l$4afbedeb
> bra.s   sad_error
> dc.w'HEAP'
> which will cause the program to hang.
>
> Releasing mem that shouldn't have been could also lead to other
> interesting errors...
>
> Coming back to the initial error:
>
> bor_lvlend
> cmp.l   d4,d5; bottom of locals yet?
> bgt.s   bor_lvloop   ; ... no
>
> move.l  rt_def(a6,a2.l),d0
> neg.l   d0   ; address of definition
>
> Interestingly, the area pointed to by (A6,A2) was indeed copied from the
> old mem to the new - unfortunately, the pointer at rt_def(a6,a2.l) within
> that was not updated.
> Finding out where that pointer originally pointed to and then trying to
> set it to the corresponding new memory location does not seem trivial to
> me, and the risk of breaking the entire program just seems too great to me.
> I'd love to be proved wrong...
>
> Have fun
>
> Wolfgang
>
> ___
> QL-Users Mailing List
>
___
QL-Users Mailing List

Re: [Ql-Users] Problem loading extensions

[Wolf]

Hi,


Even if never fixed, any chance you could share what you found as the
cause?



Sure thing.

This is how I see the error arises:

First
When you call the vector to initialise new keywords, the corresponding 
routine (at label "sb_inipr" in smsq_sbas_inipr_asm) allocates new 
memory for the new name table and much other information, shuffles the 
content of the old into the new, de-allocates the old and does quite 
some more shuffling/updating pointers.


Second
Whenever one is in a procedure, at the end of the procedure, you come to 
label "bo_return" (in the file smsq_sbas_iprocb_asm). Following the flow 
of that you will arrive at the following code:


bor_lvlend
cmp.l   d4,d5; bottom of locals yet?
bgt.s   bor_lvloop   ; ... no

move.l  rt_def(a6,a2.l),d0
neg.l   d0   ; address of definition

Unfortunately, the address D0 now points to (which is then copied into 
A4 and used later) is now wrong. It still seems to point into some of 
the old memory that was deallocated.


Now, with a bit of luck, the content of that memory hasn't been re-used 
between the call to sb_inipr and this point in the code, so that the 
program can continue normally. If not, you will most likely get

into a heap error later:

After the above code, just before you get to the loop at label 
"bor_fploop", the adress in A4 is used to get the number of parameters 
to treat. This is most likely wrong, so the loop counter for the loop is 
(in the case I observed) much bigger than what it should have been (note 
this could also have happened at label "bor_swloop" a bit earlier on). 
In the loop at label "bor_fploop" there most likely will be a cbra to 
label "bor_fpex" to clear the (local) variables used in the procedure 
via the subroutine at label "bor_clrval".


This leads to label "sb_redat" (in smsq_sbas_aldat_asm) from there to 
"sad_rlx". This tries to release momory taken up by the (local) 
variables and, since one does that more often that is should have been, 
may lead to a heap error at label "sad_error":

sad_error
dc.l$4afbedeb
bra.s   sad_error
dc.w'HEAP'
which will cause the program to hang.

Releasing mem that shouldn't have been could also lead to other 
interesting errors...


Coming back to the initial error:

bor_lvlend
cmp.l   d4,d5; bottom of locals yet?
bgt.s   bor_lvloop   ; ... no

move.l  rt_def(a6,a2.l),d0
neg.l   d0   ; address of definition

Interestingly, the area pointed to by (A6,A2) was indeed copied from the 
old mem to the new - unfortunately, the pointer at rt_def(a6,a2.l) 
within that was not updated.
Finding out where that pointer originally pointed to and then trying to 
set it to the corresponding new memory location does not seem trivial to 
me, and the risk of breaking the entire program just seems too great to 
me. I'd love to be proved wrong...


Have fun

Wolfgang

___
QL-Users Mailing List

Re: [Ql-Users] Problem loading extensions

[Martyn Hill]

Sounds interesting Wolfgang!

Even if never fixed, any chance you could share what you found as the cause?

M.

On 22/02/2017 22:30, Wolf wrote:

Hi all,

I've found the source of the error and this seems to be a genuine bug.

However, I'm not sure that the effort required to correct this whilst 
making sure that nothing else will be broken at the same time, will be 
worthwhile. So perhaps it's best to go with Martyn Hill's suggestion : 
don't use LRESPR in a procedure/function..



On 20/02/2017 14:40, Martyn Hill wrote:

Ciao Giorgio

Some time ago, I observed and reported here a similar sounding issue
whereby LRESPR would fail from within an SBasic PROCedure. Not all of
them, but some.


Sorry I seem to have missed that


Wolfgang


I resorted to loading the very same extensions outside of a procedure,
without issue.

Regards,
Martyn Hill.

On 19/02/2017 22:42, Giorgio Garabello wrote:

HI, on QPC2 I wrote a small test program, in which load the names of
several extensions in a table and then load (LRESPR) scanning the 
table.


Code: Select all
100 WTV
110 LAUNCH
120 DEFine PROCedure LAUNCH
130DIM TAB_EXT$(3,50)
140TAB_EXT$(0) = "WIN1_CLAVIER_bin"
150TAB_EXT$(1) = "WIN1_DBAS_sys"
160TAB_EXT$(2) = "WIN1_ENV_bin"
170TAB_EXT$(3) = "WIN1_FILEINFO2_bin"
180:
190FOR I = 0 TO 3
200   LRESPR TAB_EXT$(I)
210END FOR I
220:
230 END DEFine LAUNCH


If I try to load an extension in the usual way (LRESPR filename) and 
then

load the other using the table QPC2 crash
Code: Select all
100 WTV
105 LRESPR WIN1_DBAS_sys
110 LAUNCH
120 DEFine PROCedure LAUNCH
130DIM TAB_EXT$(2,50)
140TAB_EXT$(0) = "WIN1_CLAVIER_bin"
150TAB_EXT$(1) = "WIN1_DBAS_sys"
170TAB_EXT$(2) = "WIN1_FILEINFO2_bin"
180:
190FOR I = 0 TO 2
200   LRESPR TAB_EXT$(I)
210END FOR I
220:
230 END DEFine LAUNCH


This happens with any extension.
Any idea to solve the problem?

Giorgio

p.s.
On SMSQmulator:

the first example work correctly as on QPC2
the second example reset SMSQMulator.
___
QL-Users Mailing List



___
QL-Users Mailing List


--
"There are 10 types of people in this world. Those who understand binary and those 
who don't."

___
QL-Users Mailing List

[Ql-Users] Problem loading extensions

[Wolf]

Hi all,

I've found the source of the error and this seems to be a genuine bug.

However, I'm not sure that the effort required to correct this whilst 
making sure that nothing else will be broken at the same time, will be 
worthwhile. So perhaps it's best to go with Martyn Hill's suggestion : 
don't use LRESPR in a procedure/function..



On 20/02/2017 14:40, Martyn Hill wrote:

Ciao Giorgio

Some time ago, I observed and reported here a similar sounding issue
whereby LRESPR would fail from within an SBasic PROCedure. Not all of
them, but some.


Sorry I seem to have missed that


Wolfgang


I resorted to loading the very same extensions outside of a procedure,
without issue.

Regards,
Martyn Hill.

On 19/02/2017 22:42, Giorgio Garabello wrote:

HI, on QPC2 I wrote a small test program, in which load the names of
several extensions in a table and then load (LRESPR) scanning the table.

Code: Select all
100 WTV
110 LAUNCH
120 DEFine PROCedure LAUNCH
130DIM TAB_EXT$(3,50)
140TAB_EXT$(0) = "WIN1_CLAVIER_bin"
150TAB_EXT$(1) = "WIN1_DBAS_sys"
160TAB_EXT$(2) = "WIN1_ENV_bin"
170TAB_EXT$(3) = "WIN1_FILEINFO2_bin"
180:
190FOR I = 0 TO 3
200   LRESPR TAB_EXT$(I)
210END FOR I
220:
230 END DEFine LAUNCH


If I try to load an extension in the usual way (LRESPR filename) and then
load the other using the table QPC2 crash
Code: Select all
100 WTV
105 LRESPR WIN1_DBAS_sys
110 LAUNCH
120 DEFine PROCedure LAUNCH
130DIM TAB_EXT$(2,50)
140TAB_EXT$(0) = "WIN1_CLAVIER_bin"
150TAB_EXT$(1) = "WIN1_DBAS_sys"
170TAB_EXT$(2) = "WIN1_FILEINFO2_bin"
180:
190FOR I = 0 TO 2
200   LRESPR TAB_EXT$(I)
210END FOR I
220:
230 END DEFine LAUNCH


This happens with any extension.
Any idea to solve the problem?

Giorgio

p.s.
On SMSQmulator:

the first example work correctly as on QPC2
the second example reset SMSQMulator.
___
QL-Users Mailing List



___
QL-Users Mailing List

Re: [Ql-Users] uQLx 2017

[Graeme Gregory]

On Tue, 21 Feb 2017, at 09:29 PM, Derek Stewart wrote:
> On 21/02/17 17:18, Graeme Gregory wrote:
> >
> >
> > On Tue, 21 Feb 2017, at 04:16 PM, Derek Stewart wrote:
> >> On 21/02/17 15:38, Derek Stewart wrote:
> >>> On 21/02/17 15:23, Graeme Gregory wrote:
> 
> 
>  On Tue, 21 Feb 2017, at 03:09 PM, Dilwyn Jones wrote:
> >>> A newly revised version of the Linux QL emulator uQLx (uQLx 2017)
> >>> is now
> >>> available.
> >> Great news!
> >>
> >> Is it only me or is the 32-bit binary qm_x86-32 missing in the ZIP
> >> file?
> > Tim? Graeme? Help...
> >
>  Grudammit I did not spot that!
> 
>  I guess Tim will re-issue when he awakens!
> 
>  Graeme
>  ___
>  QL-Users Mailing List
> 
> >>> Hi Graeme,
> >>>
> >>> I have compiled UQLX 2017 on a Mint 18.1 Linux box, all work great,
> >>> except, I do not get the QDOS or Minerva startup screen asking for F1 or
> >>> F2 in QDOS or F1,F2,F3,F4 in Minerva.
> >>>
> >>> I do not like the red screen that starts up can did this be disabled.
> >>>
> >> Hi,
> >>
> >> I have just realised that the UQLX 2017 startup screen is MDV1_BOOT
> >>
> >> But How do I enable the Minerva F1-F4 Prompt, to enable the second?
> >>
> > Comment out AUTO_BOOT from boot.h and rebuild.
> >
> > I left the default as I found it.
> >
> > Graeme
> >
> > ___
> > QL-Users Mailing List
> >
> 
> Hi Graeme,
> 
> I commented the AUTO_BOOT and the BOOT_SELECT Q_F1 option out and 
> recompiled.
> 
> UQLX booted up the correct Minerva Screen, but when I selected F3 for 
> the Second Screen no cursor in Channel #0. Using F4, no Cursor and a 
> little screen corruption.
> 
> Can the AUTO_BOOT be a command line option or defined in the config file.
> 
Anything is possible, feel free to send a pull request with the patches
:-)

Ill probably not look into it in the short term as I have some other
more major plans.

Graeme
___
QL-Users Mailing List