Hi,
I’m not 100% sure if it is in dirrect connection with the topic of this thread, but I found that the CTX sample from the Vista 2 WDK under both XP SP2 and XP x64 generates thousands or even tens of thousands of stream context structures (can be seen under PoolTag CxSc tag). I observed, that after a quite short tests there are even more than 20.000 structures allocated (and NOT freed); in only a few minutes test the CTX sample alone allocated almost 10 MB of memory for the different context structures (over 2,5 MB non-paged in stream context structures); I belived that the Cache Manager or File System might keep the FCB structures alive for a non-determined time (AFAIK stream contexts use FsContext –> FCB and are released when the FCB is freed) however, even after the tests where done and a substantial time passed (~30 minutes) the memory was still allocated; could someone confirm me that this is a normal behaviour? (1 driver, 1 instance, 10 MB of pool in a few minutes?)
thank you in advance,
Alex
Fltmgr will tear down these context when the FCB is torn down. This could
take days (literally).
If the system starts to run low on memory, the system will start destroying
all these context and FCB’s. The only exception to this is if you increased
the ref count on one of these context and didn’t decrement it.
This is normal as far as I’m concerned.
m.
----- Original Message -----
From:
To: “Windows File Systems Devs Interest List”
Sent: Monday, July 24, 2006 3:02 AM
Subject: RE:[ntfsd] FltMgr STREAM_LIST_CTRL leak?
> Hi,
>
> I’m not 100% sure if it is in dirrect connection with the topic of this
thread, but I found that the CTX sample from the Vista 2 WDK under both XP
SP2 and XP x64 generates thousands or even tens of thousands of stream
context structures (can be seen under PoolTag CxSc tag). I observed, that
after a quite short tests there are even more than 20.000 structures
allocated (and NOT freed); in only a few minutes test the CTX sample alone
allocated almost 10 MB of memory for the different context structures (over
2,5 MB non-paged in stream context structures); I belived that the Cache
Manager or File System might keep the FCB structures alive for a
non-determined time (AFAIK stream contexts use FsContext –> FCB and are
released when the FCB is freed) however, even after the tests where done and
a substantial time passed (~30 minutes) the memory was still allocated;
could someone confirm me that this is a normal behaviour? (1 driver, 1
instance, 10 MB of pool in a few minutes?)
>
> thank you in advance,
>
> Alex
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Actually, I’ve noticed this for a while now and it seems to be directories that are leaking. Regarding taking days to tear down the streams, I ran tests where I had two simple batch files; one creates a file and deletes it then keeps looping and another doing the same with a directory. What I observed was the file stream contexts were cleaned up immediately but the directory contexts kept incrementing.
I reported this to Neal a few weeks back and proved sample code. They are looking into it.
Hi,
I reported this to Neal a few weeks back and proved
sample code. They are looking into it.
any feedback from Neal or where / when should I check
for corrections / updates?
btw. I was testing this also with batch files; one
like
for /r %%f in (*.txt) do type “%%f”
or
for /r %%f in (*.*) do dir “%%f”
generates A LOT of open handles, and easily several MB
of memory used in stream contexts;
thanks in advance,
Alex
— xxxxx@nsisoftware.com wrote:
Actually, I’ve noticed this for a while now and it
seems to be directories that are leaking. Regarding
taking days to tear down the streams, I ran tests
where I had two simple batch files; one creates a
file and deletes it then keeps looping and another
doing the same with a directory. What I observed was
the file stream contexts were cleaned up immediately
but the directory contexts kept incrementing.
I reported this to Neal a few weeks back and proved
sample code. They are looking into it.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as:
xxxxx@yahoo.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Yes, there seems to be something about context cleanup not firing for directories. It’s pretty apparent when you track the tags. It looks like the Filter Manager is not getting the teardowns for them. One could argue that it’s to be expected and I agree that teardown doesn’t always happen right away but, from what I observed, the directory contexts were never getting torn down.
I too used the Ctx sample to verify this because I suspected I was making a mistake. But I had the exact behavior in two mini-filters so either I was making a globally incorrect assumption or something else was going on. The original Ctx sample I used was from the pre-Vista IFS kit (I believe it was SRV03SP1) and that version of the sample only built up contexts for files. So when I ran it, I didn’t see any leaks and I thought it was my bug. Then I noticed that it didn’t track directories and after I added that - BAM - there was what appeared to be a leak.
As an aside, when you unload your mini, you get the cleanups on all the streams then which makes sense. That seemed to be the only way (short of dismounting the volume) to flush those stale contexts.
jerry