On Friday 06 December 2002 19:41, Ludovic Rousseau wrote:
> > (Actually, it doesn't. I've tried closing it and zeroing isExecuted
> > here. It didn't hurt anything, but didn't help the memory leak
> > either.)
>
> I don't see where the � memory leak � is.
> The SYS_OpenFile(PCSCLITE_PUBSHM_FILE, O_RDONLY, 0) in
> src/winscard_clnt.c does not _allocate_ memory. The memory allocation is
> done by src/eventhandler.c on the daemon side.
>
> Why do you call it a memory leak? I think it is more a file id leak.
I'm sure you are right. I didn't want to assume too much in giving it a name,
and the only symptom that was certain was sbrk() returning about 40K more
after every password check. It seems very likely this increase was in the
file table.
Since my last posting, I have added a SHMClientCloseSession() just before
the SCardRemoveContext(hContext) call in SCardReleaseContextTH. This seems
to fix the average case, although further testing is required. As it stands,
SHMClientCloseSession will not be called if there is an error before the
natural end of SCardReleaseContextTH. If there were a way to systematically
reproduce a situation like that, it could lead to security problems.
While testing that, I tried removing the card altogether, and typing a large
number of false passwords. This brought up a new instance of a similar
problem (xscreensaver dies, upon which event pcscd suddenly closes about
thirty open files). I have looked into this a bit.
It comes from the same file problem. Since EstablishContext fails, the
musclecard code doesn't bother to call ReleaseContext, so nothing either
frees mapaddr or calls SHMClientCloseSession. It seems to me that this would
all be easier if we did away with the whole isExecuted section, perhaps
replaced with a static function for opening/closing internal state. That
way, instead of "isExecuted," it would be something like "isActive," and
could be closed any time the calling application might reasonably just go
away.
The section protected by isExecuted in SCardEstablishContextTH could be moved
to a function "internal_ensureActive" (or something like this) and a new
function "internal_freeStatic" (ok, I'm not good with names) would do
something like this:
static void internal_freeStatic() {
if (isExecuted) {
if(mapAddr) {
SYS_CloseFile(mapAddr);
mapAddr = 0;
}
SHMClientCloseSession();
isExecuted = 0;
}
}
It would only be called from inside SCardEstablishContextTH or
SCardReleaseContextTH, so the thread locking would already be handled. The
new function could then be called from each error return in
SCardEstablishContextTH and also just before every return (including errors)
in SCardReleaseContextTH.
I don't want to try implementing any of this before looking at the 1.1.2 code,
but am about to look at that now.
What do you think?
-- Mike.
-----------------------------------------------------------------------
Michael Nidd
IBM Zurich Research Laboratory
Saumerstrasse 4
CH-8803 Rueschlikon/Switzerland
[EMAIL PROTECTED] Tel: +41-1-724-89-30 Fax: +41-1-724-89-53
What you want, what you're hanging around in the world waiting for,
is for something to occur to you. -- Robert Frost
_______________________________________________
Muscle mailing list
[EMAIL PROTECTED]
http://lists.musclecard.com/mailman/listinfo/muscle
