Re: Process & memory usage guru question

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Thanks agian for the information.

Aside from Bogdan's & Stephasn's post about using
http://www.softwareverify.com/cpp/memory/index.html,
are there any specific tools in the "Windows Resource Kit", "Debugging Tools
for Windows", or www.sysinternals.com that you are aware of specifically for
nailing these handle leaks?

I have been trying to use OH.exe that is available in the "Windows Resource
Kit" with soem results, but is somewhat like pulling teeth.

I will probably post this more specific question in the WinDbg group as
they've been very helpful in the past.

Thanks!

"Joseph M. Newcomer" wrote:

And specifically, if you act as if memory cannot be exhausted, your program will fail in
strange and wondrous ways which are quite unpredicable.
joe

On Tue, 24 Oct 2006 09:49:02 -0700, j.a. harriman <jeffrey_no_spam_alias@xxxxxxxxxxxxx>
wrote:

I want to say that I appreciate everyone's input on this.

One thing that I'm not fully understanding is, what is the siginificance of
the increase in handles as well as incredibly huge numbers (100s of
thousands) of "page faults" - identified by "Task Manager"?

What are the ramifications to the programs having the issue, the programs
they call (CreateProcess), and the operating system (Server 2003),
**assuming** that physical memeory is not exhausted?

It isn't just our code, but McAffee's AV as well.

Thanks. Jeff

"Joseph M. Newcomer" wrote:

First, there was never a need to run "cmd". For example, if you want to run a program
using some command line to the shell, such as
"zipit file1 file2 file3"
you can do this one of two ways, directly, with CreateProcess:
TCHAR cmdline[] = _T("file1 file2 file3");
CreateProcess(_(T"zipit"), cmdline, ...);
or
TCHAR parms[] = _T("zipit file1 file2 file3");
CreateProcess(NULL, parms, ...);

It is important to note that the second parameter must be an LPTSTR (writeable string),
not an LPCTSTR (constant string). If you have a CString, you can pass it in as
CString cmdlne = _T("zipit file1 file2 file3");
LPTSTR p = cmdline.GetBuffer();
CreateProcess(NULL, p, ...);
cmdline.ReleaseBuffer();

make sure, when you are testing for return, that all paths will eventually do a
ReleaseBuffer; otherwise you can get access faults and other unpleasant experiences.

Now as to the handle leak: if you don't do a ::CloseHandle on the process and thread
handles returned by ::CreateProcess (in the PROCESS_INFO block), you will leak two handles
on each launch.

There is ZERO chance that any memory problems in appB will have any effect on appA. The
address space for appA is completely separate from that of appB.

You can be very, very confident that in almost any situation in which you launch a command
shell there is a better way to do it. Assume this is always true, and in the rare cases
where it will not be, and you need a genuine command shell, you will then recognize this
as one of these exotic situations. They are very, very rare.
joe

On Tue, 17 Oct 2006 06:02:01 -0700, j.a. harriman <jeffrey_no_spam_alias@xxxxxxxxxxxxx>
wrote:

Hello,

We have a C++ console app (AppA) (multithreaded - uses _beginthread) that
runs as a batch program. Within **each** thread we may, depending on a
number of bools, start another console app (AppB) to do zipping of files on a
share using pkzip.

To start the AppB app that does the zipping, we call one of our DLL
functions that uses the "CreateProcess" defined in the "winbase.h" header.
It calls a "*cmd" file that kicks off AppB.

This pgm. has worked for a long time, but frequently the threads where the
"zipping of the files" is occurring begin to fail in large numbers,
apparently unable to locate files or access a drive. Other unrelated
programs running on the same server have no issues accessing the same
drive/share.

This happens 1 a week or 1 every 2 weeks. The program shuts down and does
not create a Dr Watson dump. I have not attached ADPLUS at this point.

The program is leaking handles and I am working on narrowing that down.

I have two questions:
1.) AppA has "X" amount of memory that it uses for its processing, but when
the threads kick off these "cmd" files to do the zipping, my guess is that
they do not run within AppA's memory space. Even though it "shouldn't"
happen, I believe memory is getting corrupted causing AppA to see these
failures. Is this correct?

2.) Is there a betterr way to call AppB (which requires command line
params.) than the method that we've employed?

Thanks for making it this far. Jeff
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

.

Relevant Pages

  • Re: Process & memory usage guru question
    ... There is ZERO chance that any memory problems in appB will have any effect on appA. ... To start the AppB app that does the zipping, we call one of our DLL ...
    (microsoft.public.vc.mfc)
  • Re: Process & memory usage guru question
    ... There is ZERO chance that any memory problems in appB will have any effect on appA. ... To start the AppB app that does the zipping, we call one of our DLL ...
    (microsoft.public.vc.mfc)
  • Re: Process & memory usage guru question
    ... As far as thread pools go, AppA has an item to process, it calls the ... CreateProcess to execute cmd.exe to start AppB. ... AppB launches pkzip. ...
    (microsoft.public.vc.mfc)
  • Re: Process & memory usage guru question
    ... AppB launches pkzip. ... I am still uncertain as to why AppA is exiting unexpectedly. ... CreateProcess() when you simply want to run pkzip to compress files. ...
    (microsoft.public.vc.mfc)
  • Re: Process & memory usage guru question
    ... personally like Memory Validator at ... To start the AppB app that does the zipping, we call one of our DLL ... I believe memory is getting corrupted causing AppA to see these ...
    (microsoft.public.vc.mfc)