[JDEV] Dangling pointers, ref counting and concurrency
David Le Corfec
david.le-corfec at idealx.com
Fri Nov 17 15:05:14 CST 2000
This is somewhat related to my post "memory handling problem in jabber 1.2"
from Wed, 15 Nov.
It may happen that js_mapi_call() is called with a user
that has both ref == 0 and sessions == NULL.
This user can then be destroyed at "any" time by the asynchronous
_js_users_del() (even with non-premptive threads !)
You don't want an user to be destroyed in the middle of a
jsm module handler. It hurts :)
My fix proposal is to increment user->ref at the beginning
of js_mapi_call(), and decrement it before the returns (trivial patch
not included)
Anyway, it seems logic for a ref counter to be incremented when
you have a line like "m.user = user;"
I think the ref counter should be incremented earlier, but
I don't know where it should be incremented/decremented
to guarantee both properties:
- you can never use a pointer to a freed user
- unneeded users are freed
As a related note, now that an xdbcache request can be resent
safely (because the user data is still there), while the
xdb request is pending another user cannot login (it stalls
after js_packet() on the auth message).
After xdb_thump has wacked the old xdb request (after 30 s),
authentication of the other user resumes. Not very nice.
Why ?
(all this when doing an xdb get request, and making the xdb
instance return without delivering an xdb result)
--
David Le Corfec
More information about the JDev
mailing list