Jeff Reid

I wrote a program that copies all the files and directories from a volume (or directory) to another directory. It doesn't appear to be leaking any resources, but it stopped one time and I couldn't open up any other windows. I ran it again under XP X64 and it ran OK.

I reran it again under 32 bit XP and it ran OK, so I'm not sure what went wrong.



Re: Visual C++ General Running out of resources

Ramkrishna Pawar

What window, how many windows were open Have you tried calling _CrtDumpMemoryLeaks




Re: Visual C++ General Running out of resources

Nishant Sivakumar

For all you know it might have been due to some other malfunctioning program or even a hardware error (hard disk or memory). But to be sure you'd just have to enforce some thorough testing and then some more!





Re: Visual C++ General Running out of resources

Simple Samples

It is not likely anyone can determine the problem without more information. There are hundreds of possibilities. One of many possibilities is stack space, if your program uses recursion.




Re: Visual C++ General Running out of resources

Jeff Reid

As mentioned, it was probably something unrelated. I ran the copy program again, then launched another program, and exited the other program while the copy program was running, and the copy program ran just fine.

Regarding recursion, I have an array of global WIN32_FIND_DATA structures, handles, and pointers to source and destination path strings to deal with FindFirstFile / FindNextFile. The main working routine does call itself, but has no local variables and no paramters, so it's just the registers that get saved on the stack. I doubt the directory depth is even close to 32 deep, although I've set it up for 128.

The recursion isn't really needed, and I'll probably eliminate it. For each directory, there are two main loops, the first loop processes all the files in the current directory (to keep all files of a directory together on the hard drive). The second loop processes all the directories in the current directory; for each time sub-directory, a global index is incremented, the paths are extended to include the sub-direcotry, and the code reverts back to the first loop for processing the files. A "goto" would work just fine, but I used recursion instead. It would be a minor change. As mentioned, the index and the arrays eliminate any real need for recursion.

I'll test it again and confirm.





Re: Visual C++ General Running out of resources

Ted.

Sounds like you may not be calling FindClose on the handles returned by FindFirstFile



Re: Visual C++ General Running out of resources

Jeff Reid

Ted. wrote:
Sounds like you may not be calling FindClose on the handles returned by FindFirstFile
I checked the handle count in Task Manager before and after a run, and the count remains the same.





Re: Visual C++ General Running out of resources

Simple Samples

Jeff Reid wrote:
I checked the handle count in Task Manager before and after a run, and the count remains the same.

I am not sure that the Task Manager counts those handles, but even if it does, Windows would get rid of them when the program exits. You need to somehow determine if there are unneeded handles open during execution.






Re: Visual C++ General Running out of resources

Jeff Reid

Handle count remains about the same during a run. Actually for some strange reason, the handle count sometimes decreases while the program is running.





Re: Visual C++ General Running out of resources

Ted.

one thing you didn't answer, are you actually calling FindClose on the handles returned by FindFirstFile



Re: Visual C++ General Running out of resources

Simple Samples

I think he is assuming that the Task Manager is useful for this and is acting based on that assumption. If that assumption is not valid but he persists with it then we can't help. You are saying that he should look at the source code, and he certainly should, but the assumption that the Task Manager is useful is providing an excuse to ignore the source.






Re: Visual C++ General Running out of resources

Jeff Reid

>find close

Yes the program is issuing find closes.

>memory leak

I added memory leak debug code and there wasn't any (at least on a shorter run)

>task manager

Handle counts seem to change, but if there's a better tool I'll try it.

< problem / issues description

It is a large copy, 150GB and several hundred thousand files (200K or 700K files, need to do another list files on this).

If I drag and drop from Windows desktop to do the copy instead of my program, it has issues as well.

If I run task manager while the copy program is running, and set it's priority to low, and let Task Manager continue to run, the program works OK.

Running the same program or drag and drop from Windows desktop works OK on Windows XP X64, but not 32 bit Windows XP Pro.





Re: Visual C++ General Running out of resources

Ted.

ok I understand - if it is truly having problems even using drag and drop, then XP 32 may actually be hitting some sort of resource limitation as you've already seen. Not sure what can be done for this unfortunately, other than possibly contacting Microsoft PSS about this issue.



Re: Visual C++ General Running out of resources

Jeff Reid

XCOPY from dos console prompt does work in 32-bit XP. I plan on investigating this further.

I use this copy routine to backup / restore partitions, and wanted to retain short names and date/times stamps, which is why I wrote it. I've already got a workaround, leave task manager running and reduce priority in 32-bit XP, or just run it under XP X64. I have to run XP X64 in order to backup / restore the 32 bit XP parition, so doing one more partition while running under XP64 is ok.

The actual sequence I use is backup / compare / format / restore / compare to backup and defrag paritions. I'm using windiff for the compare, but may write my own compare to speed things up. Even with multiple hard drives, it still takes a while to backup that one large parition.





Re: Visual C++ General Running out of resources

markmo

I see this exact same problem on my machines with large hard disks when backing them up using Microsoft's ROBOCOPY tool. I'm backing up between 300mb and 450mb of data to a USB drive from my internal SATA or SCSI drives. The whole system becomes painfully slow when the failure is occuring and ROBOCOPY is reporting the error. It doesn't even seem to have to do with actual file copies, just the enumeration of that many files to see if they need to be copied (based on timestamps). I use XPSP2, 32bit. I have not found a working solution either.