Re: [Ql-Users] Problem loading extensions
On 23 February 2017 at 08:44, Giorgio Garabello wrote: > Ok, many thanks to all > Wolfgang i suggest you to explain this LRESPR's "limit" in the next version > of the SMSQ/E manual. > The simplest solution would be to return an error from BP.INIT (or the equivalent SMSQ vector) when called from inside a procedure. It's not the LRESPR itself that causes the problem (it's perfectly valid to load and init something into RESPR/ALCHP from a procedure as long as it doesn't contain S*Basic extensions). However not all extensions recognise this error return and thus would not report this to the user. I don't expect this to cause any harm though, the only effect would probably be that the new keywords would not work. Right now the same error occurs when your new extensions have invalid names. I got caught once when I wrote a function 'MOD' which does the same as the MOD operator but with floating-point numbers, which all QDOS versions up to JS (and probably Minerva) happily accepted but SMSQ rejected... Jan ___ QL-Users Mailing List
Re: [Ql-Users] Problem loading extensions
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
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
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
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] Problem loading extensions
Bob Spelten wrote: Strangely I can. When run, the system hangs (padlock) so not a total crash. I did replace the DBAS inside LAUNCH with ENV_bin from the first code block, no point in doing DBAS twice. I do remember a long time ago I had a similar problem in my BOOT and Jochen Merz advised me to take the LRESPR out of the Proc, as Martyn Hill suggested. The question is if this is due to one of the extensions themselves or would any set of _bins give problems this way. Some things to consider, going back to first principles: 1. Does it give the same results with odd and even length binary files? 2. Rearrange the order of the files - any difference? 2. Could LRESPR in a procedure be introducing some form of stack imbalances or stray bytes in the name table? 3. Go back to first principles, LRESPR one file at a time and add one at a time until you find the one that causes the error. 4. Replace the LRESPR with RESPR/LBYTES/CALL to see if the same thing happens. 5. If you can, use different versions of the same extensions just to test it's not an oddity in one particular version of one of the extensions sets. I'm not convinced installing an extension within a procedure is a good idea anyway - whether it works or not, it seems poor style. I always put them inline like in a boot program. It's also not good practice to install extensions and use them in the same program as this will upset pre-JS ROMs in a big way (OK,not a problemif a programis *only* for SMSQ/E) Dilwyn (whose space bar isplaying up, sorry) ___ QL-Users Mailing List
Re: [Ql-Users] Problem loading extensions
Op Mon, 20 Feb 2017 15:22:16 +0100 schreef Marcel Kilgus : Giorgio Garabello wrote: 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? I can't reproduce your problem, sorry. Marcel Strangely I can. When run, the system hangs (padlock) so not a total crash. I did replace the DBAS inside LAUNCH with ENV_bin from the first code block, no point in doing DBAS twice. I do remember a long time ago I had a similar problem in my BOOT and Jochen Merz advised me to take the LRESPR out of the Proc, as Martyn Hill suggested. The question is if this is due to one of the extensions themselves or would any set of _bins give problems this way. Bob -- The BSJR QL software site at: "http://members.upc.nl/b.spelten/ql/"; ___ QL-Users Mailing List
Re: [Ql-Users] Problem loading extensions
Giorgio Garabello wrote: > 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? I can't reproduce your problem, sorry. Marcel ___ QL-Users Mailing List
Re: [Ql-Users] Problem loading extensions
Many thanks! 2017-02-20 14:40 GMT+01:00 Martyn Hill : > 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. > > 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 >> > > -- > "There are 10 types of people in this world. Those who understand binary > and those who don't." > > ___ > QL-Users Mailing List > ___ QL-Users Mailing List
Re: [Ql-Users] Problem loading extensions
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. 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 -- "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
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
