|
|
|||||||
Has anyone found any issues that may prevent this build from becoming a RELEASE version? Please post any issues related to this build so that we can hopefully get it compiled as a release if no one finds or reports any issues. |
||||||||
|
|
|||||||
So no one is using or tyring this version? or it is ready for Production status? |
||||||||
|
|
|||||||
I have found noting serious All my script run with no modification, so i'm tempted to release a beta into production. The only issues i have found until now is that the Set command dosn't work on Win95, but since it hasn't worked in previous versions, this shouldn't prevent an upgrade. Another small one is that if you use MessageBox() from a DOS console the messagebox dosn't get focus the focus stays on the DOS console. This last one i have only seen when running KiX32/WKiX32 from WinXP -Erik |
||||||||
|
|
|||||||
I haven't anything wrong either. However, it seems that COM is now working like a charm |
||||||||
|
|
|||||||
Okay, I have to revers my statement, I did find something, might be a memory leak. The code posted below was run on a Pentium-III 1000 with 512MB RAM under Windows 2000 Server. It fails around the number combination 8,2,0,0 with an 'out-of-memory' error. Beforehand, memory consumption (as displayed in the Task Manager) is increasing constantly. Additionally, in case of divisions by 0 , no 'division-by-zero' error is created but the division results in a mathematically incorrect '0'. code:BREAK ON |
||||||||
|
|
|||||||
Shawn, Howard, Alex, Lonkero, etc... Can anyone else analyze and confirm this to be a possible bug? |
||||||||
|
|
|||||||
doc, hoby has seen something and so have I. just have to see that it really is kixtart and not the add-ons doing this... |
||||||||
|
|
|||||||
I have been out of it for a while.. Were we able to get the Access, SQL DB query stuff resolved with the new version? Thanks! Kent |
||||||||
|
|
|||||||
what I've seen on the board, they seems to working again... still I wonder, what is the use if there is exchaustive access to DB and all kix gives is an: "out of memory" anyway, it seems that those problems were solved and the solving has introduced another stuff... like, not working set on w9x (which should work in this version, I quess...).   |
||||||||
|
|
|||||||
doc, I don't know do you use execute, but: code:caused 30M of memory usage in 1 minute.$x=0 in normal logonscript it should have no effect but for exchaustive long running scripts it is real pain.   |
||||||||
|
|
|||||||
I am getting out of memory errors when I leave my remote administation script running for about two hours with version 4.12 Beta 1. I have been running a variation of this script since version 3.63 and have never received an out of memory before. My script is text based, so you can take kixforms out of the equation. |
||||||||
|
|
|||||||
krabourn, It has already been shown that Execute() is leaky. Does your admin script have any Execute() statements? If not, then you should take apart your script and test them piece by piece to see where the leak may be and post the results. TIA |
||||||||
|
|
|||||||
I don't use execute. I have call, shell, run and some WMI COM calls. Those are the closest to execute that I can think of. I guess I will have to check these out. |
||||||||
|
|
|||||||
OK, Here are my results. All of my tests lasted 60 seconds. EXECUTE Execute kept climbing the whole time. Start: 172,532 K Finish: 191,420 K Difference: 18,888 K code:CALLBreak on Call kept climbing the whole time. Start: 172,368 K Finish: 179,836 K Difference: 7,468 K code:TEST-CODE.KIXBreak On code:RUN$x=kbhit() Run held steady. Start: 172,532 K Finish: 178,552 K Difference: 6,020 K code:SHELLBreak on Shell held steady. Start: 172,564 K Finish: 173,340 K Difference: 766 K code:WMIBreak on WMI held steady. Start: 185,336 K Finish: 186,636 K Difference: 1,300 K code:Hope this helps.Break on |
||||||||
|
|
|||||||
Interesting leak using CALL. Good work documenting. I think we will have some fix requests for Ruud when he gets back. |
||||||||
|
|
|||||||
Yeah - think one can see a pattern emerging - not outside the realm of possiblility that CALL and EXECUTE might share the same code. |
||||||||
|
|
|||||||
Call & Execute both leak in 4.02 also. |
||||||||
|
|
|||||||
Call is probably the closest to Execute. I have one script that I made, for controling services, before there were UDFs and I have not converted it. I use Call to access it. I guess this is a good insentive. |
||||||||
|
|
|||||||
|
||||||||
|
|
|||||||
just don't break COM again |
||||||||
|
|
|||||||
In short: thanks for all the info. I'll look into this and let you know what I find. Ruud |
||||||||
|
|
|||||||
Just to report that I indeed found a memory leak in the script execution handler. Relatively minor leak, but in tight loops as in the samples above, it can quickly lead to rather dramatic effects... Beta 2 of 4.12 will include a fix for this particular issue. Thanks again for all the information. Ruud |
||||||||
|
|
|||||||
also, the build numbers could change as new versions come along. I've understood it's been 104 for a long time. |
||||||||
|
|
|||||||
Dear krabourn, Did you have still memory leaks during execution of your examples? Did other guys detect also memory leaks in latest kixtart 4.12 build 112 release? greetings. [ 07. December 2002, 10:19: Message edited by: MCA ] |
||||||||
|
|
|||||||
the leaks were gone by the fix. |