FlashFXP Forums - View Single Post

Yil · 04-26-2010, 11:50 AM

pion: Is App Verifier running and all the options it can check enabled? I'd really like to see if it's spotting something...

Regarding extra memory usage during dumps... Most processes in the computer don't have all their pages in memory all the time. Unused or rarely used memory pages are swapped to disk to make room for more commonly used pages in other applications. The size of the memory used by looking at the default "memory" column in task manager is not the applications true size. There are at least 5 ways to measure memory but committed pages should be closest to its complete memory footprint. So what happens when you create a dump? You have to write to the dump file all the memory of the process which means the system will swap in all those unused pages from disk and even the shared .dll files. Thus the memory footprint during dump creation is essentially it's committed size and would appear to you to be growing if you just looked at task manager's default column. On a low memory computer it might actually have to swap in some pages and out some already written pages so it's memory size might never equal it's commit size at any point in time, but trust me it would if it could.

During the generation of CrashLog.txt however ioFTPD loads parts of the .pdb files so it can print function names instead of memory addresses on the stack traces. So it's true that it also consumes more memory during dump generation from within ioFTPD. This should not happen when done via windbg or any other debugger though.

I'll have to look into why windbg is having issues connecting to the process. It's interesting to me that it mentions the loader lock, but obviously it isn't completely stuck as that should be caught now. I should also point out that if the loader lock really was stuck we would see that by doing an analysis of the dumpfile and this is not the case in any of your dumps thus far unlike other people who really did have this problem.

My guess is this is a windows socket/handle problem. ioFTPD could be doing something wrong and I'll try and review the code, but Application Verifier should be the first line of attack to determine this... It's also possible my attempt to fix libmysql didn't work or I missed something.

04-26-2010, 11:50 AM
Yil Too much time... Join Date: May 2005 Posts: 1,194	pion: Is App Verifier running and all the options it can check enabled? I'd really like to see if it's spotting something... Regarding extra memory usage during dumps... Most processes in the computer don't have all their pages in memory all the time. Unused or rarely used memory pages are swapped to disk to make room for more commonly used pages in other applications. The size of the memory used by looking at the default "memory" column in task manager is not the applications true size. There are at least 5 ways to measure memory but committed pages should be closest to its complete memory footprint. So what happens when you create a dump? You have to write to the dump file all the memory of the process which means the system will swap in all those unused pages from disk and even the shared .dll files. Thus the memory footprint during dump creation is essentially it's committed size and would appear to you to be growing if you just looked at task manager's default column. On a low memory computer it might actually have to swap in some pages and out some already written pages so it's memory size might never equal it's commit size at any point in time, but trust me it would if it could. During the generation of CrashLog.txt however ioFTPD loads parts of the .pdb files so it can print function names instead of memory addresses on the stack traces. So it's true that it also consumes more memory during dump generation from within ioFTPD. This should not happen when done via windbg or any other debugger though. I'll have to look into why windbg is having issues connecting to the process. It's interesting to me that it mentions the loader lock, but obviously it isn't completely stuck as that should be caught now. I should also point out that if the loader lock really was stuck we would see that by doing an analysis of the dumpfile and this is not the case in any of your dumps thus far unlike other people who really did have this problem. My guess is this is a windows socket/handle problem. ioFTPD could be doing something wrong and I'll try and review the code, but Application Verifier should be the first line of attack to determine this... It's also possible my attempt to fix libmysql didn't work or I missed something.