|
Forum List • Thread List • Refresh • New Topic • Search • Previous • Next  1  |
 1. FIX for RAM leak in RQ calls#891 Posted by: 2003-05-09 03:47:19 |
I have used a debugger on an unpacked version of a very simple RQ program to trace the RAM leak problem. This announces that the problem is now completely understood and the code analyzed. Exactly 4 bytes of and internal RAM buffer used by RQ to nest SUB/FUNCTION calls is lost with each call.
We are not at the top of the mountian, since it is now known exactly what code is run for the End/exit SUB/FUNCTION byte code which is 0A 05 00 00 00 0B.
The code must reset a pointer in what I call the call return buffer which consists of offsets to the next RQ bytecode instruction which of course must be remembered. What is lacking is a reset of a pointer to a location for a possible next call during a SUB/FUNCTION. Two values here have to have 4 subtracted to "reset" the pointer when the above bytecode instruction is executed.
Right now I am considering how to patch the library so that the missing code (in assembler) can be added to remedy this problem. Stay tuned.
Meanwhile, if you have programs that call a sub only once from one place, just put your sub code in-line and don't use a SUB or FUNCTION structure at all. If your programs are short or run for a short time, this bug may be irrelevant.
My programs are meant to run for days or weeks at a time, so then the mem leak is relevant. |
2. Re: FIX for RAM leak in RQ calls #893 Posted by: 2003-05-09 10:49:38 |
The RAM lead is fixed!! Thus, with my patches to the libraries, your RQ programs will no longer eat up RAM as they run with SUB/FUNCTION calls. Also, certain other problems (were there any?) regarding nesting of SUB and FUNCTION calls may also be solved with this fix.
I have patched and tested the library used by my test programs. Now I will try to patch all of the libraries and make them available for DL on my web site, NetCensus.
Any other major bugs in RQ? |
3. Re: FIX for RAM leak in RQ calls #899 Posted by: Gerard 2003-05-09 23:15:26 |
Yes there are other bugs.
I.e. the read in QRegistry of a Dword value from the registry. If you try to read the value key, which tells you if a proxy server should be used or not, then RapidQ generates an error that it can not read that particular key. Even a next attempt results into the same error. After running i.e. iexplorer solves it. String values and Binary values, as far as I have seen, are free of this bug.
I always use string values as a work-around, but if you have to read system settings...
Hopefully, you can take a look if you find it interesting.
Regards,
Gerard |
4. Re: FIX for RAM leak in RQ calls #912 Posted by: 2003-05-13 11:01:01 |
I read somewhere --ezboard?-- that problems with the dword values in RQ may be due to the fact that LONG values in RQ are signed. So in RQ, hFFFFFFFF = -1 but in dword it is a big positive number. You have to work around that.
Also, it sounds that the OS may be "protecting" certain Reg keys from reading? I don't know. Does this happen? You are trying to read a key for a MS program (which further is not running). Maybe you SHOULD get an error message on that... ?? W98? or W2K? |
5. Re: FIX for RAM leak in RQ calls #922 Posted by: Gerard 2003-05-14 04:25:26 |
Hi Doc,
What I’ll do, I'll post a part of the source. Probably you are right. This nasty MSB set will result in a negative value. I am having the same trouble with the TIMER. If your server is running for more then xx days, this number results into a negative value. So, I thought to be smart and worked around it. Result: Difference of 1.5 day and a few hours. I checked it with a program of Winternal. At the end I have used the API call to do the job. But man, we are talking about the same counter. Remember the counter used in the DOS environment. It updates 18.3 times a second. It is a hardware interrupt (System Timer IRQ 0). It is still used. Its start directly when your OS is up and running. I am not sure about the last statement. It is possible that the BIOS is doing the job.
OK, next post will be the part of the source with the registry key request in it.
l8ther,
Gerard |
6. Re: FIX for RAM leak in RQ calls #932 Posted by: 2003-05-17 23:45:33 |
TIMER is a Single value, dude, not LONG
So,
DIM Time as SINGLE ' OR DIM Time(1 to x) As SINGLE
time = Timer
' later
IF Timer-time > 30.0 THEN Goto SomethingTimedOut
'
In GypsyProxy, I reset all Time(n) [I have an array of those] at midnight by doing something like this in a loop:
IF Time(n)>Timer+10.0 THEN Time(n)=Timer 'Timer should be greater.
I don't use QTimer (too difficult; programming is hard enought).
Re number of days, just remeber that Timer resets at midnight and you have to keep track of days on your own. |
7. More bugs #946 |
Are these known bugs also fixed as coproducts of the new patch?
http://g.yi.org/Software/RQ%20intro/Bugs/ |
8. Re: FIX for RAM leak in RQ calls #948 Posted by: Gerard 2003-05-19 02:53:05 |
Doc,
Here is a part of the code I'm using
Because I need no fragments, I convert it to an Integer.
This is what I have done:
DIM RunTime AS INTEGER 'I do not need fragments. INTEGER = LONG in RapidQ
DIM Days AS SHORT 'Could be more then 255 days
DIM Hours AS BYTE ' Max is 23
DIM Minutes AS BYTE 'Max is 59
DIM Seconds AS BYTE 'Max is 59
RunTime = INT(TIMER) 'Total seconds of OS running
Days = Runtime 86400 'Calculate number of days
RunTime = RunTime MOD 86400
Hours = Runtime 3600 'Calculate number of hours
RunTime = RunTime MOD 3600
Minutes = Runtime 60 'Calculate number of minutes
Seconds = RunTime MOD 60 'Leftover is number of seconds |
9. Re: More bugs #956 Posted by: 2003-05-21 08:27:42 |
My patch(es) result in correct maintenance of scratch RAM pointers used by RQ Basic. While the RAM leak was associated with the END/EXIT SUB/FUNCTION statements, the "look" of this RAM area is that it can be used for any temporary storage.
The pointers corrected point to the next free location to store something. Therefore, any part of the code could use this temporary storage. Once the value is "retreived" or the code has completed, it must restore the pointer to where it was. It is sort of like stack operation, except the pointer increases as new values are added to the scratch ram. Obviously every "user" of this scratch ram must leave the pointer where it was.
The bug I fixed was the END/EXIT SUB/FUNCTION "user" of the scratch ram failed to reset the pointers.
This failure could cause errors in nested calls (but now it is fixed).
In your list of /bugs page, I saw several of these are essentially nested calls, like calling a function as an argument to a sub call, ... yuk.
I would not be surprised if some of these kinds of bugs, and perhaps others are now fixed.
I hasten to add that I think this is poor programming practice. Don't be so lazy!
Do this:
i=Qcomponent.property
Call sub XX(i)
Not this:
Call sub XX(Qcomponent.property)
Theoreticall, the latter should work, but what if you have to debug and it
turns out that the lazy programming technique wasted many hours of your time! And I bet you thought it would be faster! |
| Forum List • Thread List • Refresh • New Topic • Search • Previous • Next 1 |
搜索
论坛
Home
回顶部
g.yi.org Hits:0
