I need help with a resource leak using multiple CreateProcess's.
There was a reported problem with NT 3.5 that was fixed in NT 4.0,
which it was. I don't know if its fixed in WinME.
I'm assuming that the problem is also in Win9x, because it surely
leaks.
The following routine is in my Build program that is used to to
assemble projects, you can assemble about 20 or 30 times with Win9x
before Windows runs out of gas and then you have to restart Windows.

I've almost given up trying to fix the problem, but someone said that
ketilO has fixed the problem.

Does anyone know what the fix is?



;_____________________________________________________________________
;---------- [Executes the batch commands] ----------
BuildCmd PROC Input:DWORD
LOCAL sat:SECURITY_ATTRIBUTES
LOCAL stin:STARTUPINFO
LOCAL prin:PROCESS_INFORMATION
LOCAL ft:FINDTEXT
LOCAL hRead:DWORD, hWrite, BytesRead
LOCAL buffer[1024]:byte

mov sat.nLength, sizeof SECURITY_ATTRIBUTES
mov sat.lpSecurityDescriptor, NULL
mov sat.bInheritHandle, TRUE
INVOKE CreatePipe, addr hRead, addr hWrite, addr sat, NULL
.if eax == NULL
INVOKE MessageBox, hWnd, addr szError3, addr AppName, MB_ICONERROR or MB_OK
.else
mov stin.cb, sizeof STARTUPINFO
INVOKE GetStartupInfo, addr stin
mov eax, hWrite
mov stin.hStdOutput, eax
mov stin.hStdError, eax
mov stin.dwFlags, STARTF_USESHOWWINDOW or STARTF_USESTDHANDLES
mov stin.wShowWindow, SW_HIDE

;---------- [Multiple CreateProcess's causes a resource leak in Win98, fixed in NT 4.0 >] ----------
INVOKE CreateProcess, NULL, Input, NULL, NULL, TRUE, NULL,
NULL, addr szPath, addr stin, addr prin
.if eax == NULL
INVOKE CloseHandle, hRead
INVOKE CloseHandle, hWrite
INVOKE MessageBox, hWnd, addr szError4, addr AppName, MB_ICONERROR or MB_OK

.else
INVOKE CloseHandle, hWrite
INVOKE CloseHandle, prin.hProcess
INVOKE CloseHandle, prin.hThread
.while TRUE
INVOKE RtlZeroMemory, addr buffer, 1024
INVOKE ReadFile, hRead, addr buffer, 1023, addr BytesRead, NULL
.if eax == NULL
.break
.else
INVOKE SendMessage, hREdit, EM_SETSEL, -1, 0
INVOKE SendMessage, hREdit, EM_REPLACESEL, FALSE, addr buffer
INVOKE SendMessage, hREdit, WM_PAINT, 0, 0
.endif
.endw
INVOKE CloseHandle, hRead
.endif
.endif
ret


Thanks,

Ewayne
Posted on 2002-05-14 13:52:07 by Ewayne
Hi,

Just a note if the assembled output .exe or .dll
is less then 10k there is not a resource leak.

By the way ketilO's RadAsm still has a resource
leak when assembling using Win9x.

Ewayne
Posted on 2002-05-15 10:41:54 by Ewayne
Hi,

After doing some playing around it appears that
the CreateProcess is not causing the resource
leak in AsmEdit or RadAsm using Win9x.

What I done for a test was to create a batch file
for some of my programs and then run the different
batch files while monitoring the resources.

Some of the compile, assemble, and links leaked
resources and some didn't and they were consistent,
by that I mean test 1,2 and 3 always leaked and
test 4,5, and 6 freed all of the resources no
matter what order I ran them in.

What was neat about the whole thing was after I
would run the test on the batch files that leaked
untill the available resources were very low and
then ran one of the batch files that freed the
resources, it brought back all of the resources.

That even worked it I opened and exited one of
MS applications that doesn't free all of the resources
on exit.

It looks like on the batch files that frees all
of the resources, during it's execution it drives
the available physical memory to zero or near zero.

Then after the program is finished Windows must
realllocate memory, reset it's control blocks,
etc. or whatever it does.

Does anyone know of a routine that I can use that
will use all of the physical memory for a test?

All that I can come up with is routines that drive
the CPU to 100%.

Thanks,

Ewayne
Posted on 2002-05-16 07:19:13 by Ewayne
have you pinpointed what causes the resource leaks?
Posted on 2002-05-16 07:26:45 by f0dder
To f0dder,

Like I said in my previous post the key thing is
when the available physical memory is driven to
zero or near zero during the assembly and link
and then after the link is finished, Windows gets
it act together and puts everything back to where
it should be.

It doesn't matter if you use a batch file, AsmEdit
build, or RadAsm, It's consistent with the same
programgs.

Thats why I need a routine to temporarily drive
the physical memory to zero to test it with the
programs where the assembly and link leaks resources.

Ewayne
Posted on 2002-05-16 07:48:24 by Ewayne
have you looked at the stress test exe that comes with visual studio?
Posted on 2002-05-17 01:36:17 by grv575
To grv575,

No I do not have Visual Studio.

I have come up with a routine that drives the
physical memory to zero, but it has some bad
side effects.

Ewayne
Posted on 2002-05-17 08:46:43 by Ewayne
Hi All,

I have come up with a solution, it's kind of
Mickey Mouse, but it works.

Thanks,

Ewayne
Posted on 2002-05-20 12:52:03 by Ewayne
Hi Ewayne,

Considering that you have conquered a long-standing well-publicized memory leak flaw in Windows 95,98,98se,ME...Mickey Mouse is very welcome on my machine!

Congratulations!
Posted on 2002-05-20 16:56:07 by gscundiff
I would love Mickey Mouse to b17xh slap my box when ever it gets cranky. Would you be willing to release your source?
Posted on 2002-05-21 00:21:03 by eet_1024
To eet_1024,

The solution to reclaiming physical is to drive
the available physical memory to or near zero.

I came up with a couple of routines that would do
that, but they would also fill up the swap file,
which was not good.

So until I or someone can come up with a better
way the following code is similar to the code
that I'm using in the build program for AsmEdit.

I just run the routing after a successful assembly
and link of a program and it reclaims all of the
physical memory back, when windows does it reclaim
it runs in the background so it's not noticable
to the user.

All it does is assembles AsmEdit, I'm not sure
what the magic is, whether it's the number of
sections or the size of the .obj files or both.
But it drives the available physical memory to or
near zero.

I'm sure other programs could be substituted.


szPathA db 'L:\\MASM32V1\\PROGRAMS\\AsmEdit\\Programs\\AsmEdit',0
szRoot db 'L:\\Masm32V1\\Programs\\AsmEdit',0
szAsmbA db '\\Bin\\ml /c /coff AsmEdit.asm MRUFiles.asm Treeview.asm Listview.asm MenuMaint.asm',0

LOCAL stin:STARTUPINFO
LOCAL prin:PROCESS_INFORMATION
LOCAL szBuffA[256]:BYTE

INVOKE lstrcpy, addr szBuffA, addr szRoot
INVOKE lstrcat, addr szBuffA, addr szAsmbA
INVOKE RtlZeroMemory, addr stin, sizeof STARTUPINFO
mov stin.cb, sizeof STARTUPINFO
INVOKE GetStartupInfo, addr stin
mov stin.wShowWindow, SW_HIDE
INVOKE CreateProcess, 0, addr szBuffA, 0, 0, FALSE,\
NORMAL_PRIORITY_CLASS, 0, addr szPathA, addr stin, addr prin
INVOKE CloseHandle, prin.hThread
INVOKE CloseHandle, prin.hProcess

I don't know if it will work on Win9x, Wim ME
machines that have large amounts of RAM (512 -
1024 meg).

Ewayne
Posted on 2002-05-21 07:17:22 by Ewayne
Ewayne, you should make the "fix code" optional... for people who
don't have problems, having memory driven near zero sucks.
Posted on 2002-05-21 09:24:10 by f0dder
To f0dder,

I don't see what the problem is, because some
programs assembled and linked under Win9x, Win ME
will already drive the physical memory to or near
zero and then Windows will reclaim the memory.

If the OS is NT, Win2k, or XP Pro I don't run the
routine.

I think everyone running Win9x, Win ME, or XP home
will have the problem.

So why not force it to reclaim the Memory???

It's tramsparent to the user and only adds a
couple of seconds to the process.

I would rather drive the memory to zero that I
don't notice then to have to reboot the system
after several (Depending on the sizes) assemblies
and links.

I sure seems nice to be able to assemble all day
and half the night and not have to reboot the
system because of lack of memory.

I may be wrong, but I think the majority of the
folks will agree with me.

Ewayne
Posted on 2002-05-21 10:07:43 by Ewayne