> Why would you assume that if you get it once you should be able to release
it twice?
I didn’t say once, I said twice: once for the alloc and once for the set.
I’ve verified that the ref count is two after these two operations. What I
don’t understand and what I don’t think is documented is why one gets an
assert if they release it twice after these two reference operations. To my
way of thinking one should be allowed to get the reference count to zero if
they have no more interest in the context, but this is impossible.
Are you saying that we are not allowed to release the reference created by
the set? The docs for FltSetStreamContext specifically say: “After calling
FltSetStreamContext, the caller must call FltReleaseContext to decrement the
reference count on NewContext, even if the call to FltSetStreamContext was
unsuccessful”.
“Neal Christiansen” wrote in message
news:xxxxx@ntfsd…
Mark,
Though not explicitly stated I believe it is implicitly stated. You do
one release for each get/alloc. If you do more then that bad things
will happen. Why would you assume that if you get it once you should be
able to release it twice?
Once a context it attached to an object (via set) the only way to detach
it is with a delete, either implicitly (when the attached object goes
away) or explicit. So the instruction pairs are:
- allocate/get must be followed by a release
- set must be followed by a delete (or implicit delete by the system)
I am glad you found your referencing issues. As I stated earlier we are
working on verifier functionality that will track everything you Get and
will tell you when you unload what you did not release.
Neal
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Thursday, March 31, 2005 4:54 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] sc stop is hanging
The only rule you don’t mention is that you will get an assertion error
if
you try to reduce the ref count to zero while the context is still
attached
to an object. This means I can only do one dereference after calling
alloc
and attach. This leaves the ref count at one until the detach, even if
I
have no interest in the context anymore.
After turning on the verifier I was able to tell what was causing the
unload
problem. I’ve now fixed all my problems in that regard.
Thanks…
“Neal Christiansen” wrote in message
news:xxxxx@ntfsd…
Mark,
You have gone to a lot of work to figure out the following basic rules:
- Whenever you allocate/get a context you must at some point release it.
- Setting a context puts an internal residual count on the context which
keeps it from going away
- Deleting a context (either explicitly by calling one of the delete
context APIs or implicitly by the object it is attached to going away)
removes the residual count.
- The context cleanup routine is called once the reference count goes to
zero.
This means a deleted context will not go away until all references go
away. You should not maintain your own list of contexts just for the
purpose of deleting them at unload time. We do this for you
automatically and all you are doing is adding unnecessary overhead.
This referencing model in the filter manager works correctly and there
are no holes or problems which makes this unusable or incorrect.
It is by design that we don’t allow your filter to unload if you have
referenced objects laying around. If it does not unload it is because
you have some sort of reference counting bug.
Anytime you retrieve a filter manager object it is referenced. This
means you must do the appropriate unreference so the object can be
freed.
We will be working on verifier features that will track all of this
information so that at unload time we can tell you exactly what you have
done wrong.
If you are still having problems with this please send me the stack
backtrace of where you are hung. I want to know if it is hung unloading
an instance or unloading the filter.
Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
Rights
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Friday, March 25, 2005 5:00 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] sc stop is hanging
I ended up doing ASSERT( (((ULONG)context)-1) == 1 ); everywhere
(which is
much safer ) and I was able to figure out what the context ref
count
rules are:
1) If you try to dereference any context still attached to an object, to
a
count of zero, you get an assertion error from the filter manager.
2) When the object that the context is attached to dissapears, there is
a
single decrement of the ref count done by the filter manager. This also
happens when you manually detach a context from it’s object using
FltDeleteContext.
3) The context-cleanup gets called only when the ref count goes to zero.
Using the above bits of knowledge, I was able to come up with an
algorithm
that worked for me:
a) Never deref an allocate function. This leaves the ref count at one
which
is balanced by the auto-decrement done by the filter manager when an
object
disappears.
b) Always deref all fltmgr calls that increment the ref count after
finding
out the call was successful. Once again this keeps the ref count at 1.
(Actually I keep the reference held for the brief period that I’m using
it
after any call).
This method caused my contexts to have their ref count go to zero
whenever a
context is detached from an object, either automatically or manually.
This
caused context-cleanup to be called at that time for all objects.
So I am convinced that my code is not leaving any contexts hanging, but
I am
still getting the “sc stop” hangup. I’ll start a new thread on this.
“Ken Cross” wrote in message news:xxxxx@ntfsd…
> Help us understand your problem better.
>
> You’re talking about a stream context, right? I don’t think the
context
> cleanup gets called until everything’s done using it, i.e., the
reference
> count goes to zero. So I doubt if what you’re suggesting will work.
>
> Furthermore, it’s probably a Bad Idea to do things like
> "(((ULONG)context)-1)=1;" because you don’t know what other parts of
the
> system (Filter Manager, file system, etc.) might be
> referencing/dereferencing the context without your knowledge. I don’t
> know
> that they do, but you should probably assume they do.
>
> Now, why can’t you release the context in post-cleanup?
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
> Sent: Friday, March 25, 2005 5:36 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] sc stop is hanging
>
>
> I found out one more thing about context reference counts. If you
> decrement
>
> the count to zero while the context is still attached to an object,
you
> get
> an assertion error.
>
> So now I know that I have to keep the context ref count to a minimum
of 1
> all the time. This means I must not release the count added by the
> allocate
>
> routine.
>
> I sure hope that the context-cleanup routine is still called when the
> object
>
> it is linked to disappears and the ref count is 1.
>
> So my current strategy (really the only one left to me) is to not
release
> the reference from the allocate but dereference all others immediately
> after
>
> they are incremented by a FltSetXXX or FltGetXXX. This means the
context
> reference count is useless.
>
> It is tempting to just sprinkle my code with *(((ULONG) context)-1) =
1;
> everywhere as a test.
>
>
>
> —
> 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
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com