This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Re[2]: memory leaks in fork(?)

> -----Original Message-----
> From: cygwin-owner On Behalf Of Mike Jastrebtsoff
> Sent: 30 January 2004 12:44

> Yep! You were completely right. I removed Agnitum Outpost and 
> my build process began to work. I wonder why stopping of 
> Outpost sevice doesn't work out - only total delete. 
> Evidently outpost has resident driver(TCP packet filter?) 
> which causes this troubles with memory leaks.

  AOF has two parts: a network intermediate (filter) driver, which is a
kernel-mode device driver, and the outpost service, which is a user-mode
win32 service.  

  The purpose of the service is to send device ioctls to the kernel-mode
device driver in order to provide a user-mode way to control/start/stop it.

  Stopping the service doesn't stop the driver, nor unload it, nor remove it
from the place it has been inserted in the driver hierarchy between the
higher-level protocol layers and the lower layer network card drivers.  The
service can send commands to the driver to make it do these things, but it
does not automatically do so when it is stopped from the services control

  In fact, the faulty network driver is installed into this hierarchy during
the AOF installation procedure, but before the system has rebooted and AOF
has run for the first time; at this point the service hasn't even been
started for the first time ever!

> I emailed to Agnitum support service and informed them about 
> this issue.

  Tell them to use Microsoft Driver Verifier on their software and enable
all the heap checking functions.  That should put them on the right track
straight away.
> Thank you very much!
> P.S. But I was shocked with MS XP complexity  - common 
> programs can have dependencies with low-level driver!

  It's not an XP problem.  Device drivers run as part of the kernel
themselves; a faulty driver effectively breaks the entire operating system.
This is the same in pretty much any OS (with the exception of user-mode
linux); if you install a faulty LKM into a linux or a bad device driver into
a SunOS, it can break the entire system in just the same way.  When
something in the kernel is trashing kernel memory space, the entire system
is going to misbehave in strange and unpredictable ways that will cause
faults for user-mode processes.  [ObCygwin:  Such as Cygwin.]

Can't think of a witty .sigline today....

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]