I was going to bring this up, but probabaly after I had done some more testing. However since /hex just brought up SysFileTree, I'll do it now.
I had wanted to include the new SysFileTree code in 4.1.2 because it definitely fixes some reproducible bugs in Linux. In Windows, I gave a version to Jerry, the submitter of the Windows bug, a version of ooRexx that had SysFileTreeB() and SysFileTree(). He tested it for a week and was able to reproduce the bug using SysFileTree 4 times in a week of testing, and never using SysFileTreeB(). Not conclusive, but an indication that the new code might fix the Windows bug. I myself tested a lot that the newer version produces the same results as the old version. However, on Friday I discovered what I thought might be a memory leak on Windows. So I won't put it in 4.1.2, but the new version does exist in trunk. What I did was put a simple routine that does a SysFileTree search for all files on my system in an endless loop. The returned stem from 1 iteration holds about 300,000 file names in the long format. On a Windows 64-bit system, memory used by rexx.exe keeps increasing until at 98% of total memory had to kill it. I have 4 GB of memory and the Rexx process used up to about 3,500 MB of it before I killed it. Since in the new version, there is the possibility of a lot more dynamically allocated memory, I first thought I had a memory leak But, these facts make me wonder if it might be something else: Running the exact same source code and same test on a Windows 32-bit machine. Memory used by the Rexx process rose to about 2400 MB and then stayed there. The system also has 4 GB of memory. I ran the test program for 48 hours and then quit because the memory had stayed steady for about 46 hours. Whereas on the 64-bit system, memory maxed out after about, I don't know exactly, but about 4 to 7 hours. I have a trial version of Purify that only runs on 32-bit. I ran the test program under it. Running one iteration, Purify report a memory loss of 28 bytes. Running 200 iterations, Purify reported a memory loss of, 28 bytes. Since it is a trial version it doesn't report where the memory loss happened. So the 28 bytes might not have even been allocated in SysFileTree. Originally in the code I was going to raise a condition if a string was longer than the static buffers. I ran that code a lot on the same 64-bit system and a condition was never raised. In the newer version, I replaced all the possible raised condition code with code that dynamically allocates memory. Therefore, in the current code, it seems possible that no dynamic memory is allocated to begin with. Making a memory leak in the new code unlikely to be the culprit. That's my next step, is to put a print out every time memory is allocated, and see if it actually happens. I still have to do that. However it's odd that the same memory problem doesn't happen on a 32-bit system. I wonder if the problem is with the garbage collector on 64-bit? -- Mark Miesfeld ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
