Commit e731ac18 authored by Rob Swindell's avatar Rob Swindell 💬
Browse files

Don't clobber an open user.dat file descriptor in js_CreateUserObject()

Likely fix for the user.dat open file descriptor leak:
If js_CreateUserObject(cx,parent,cfg,"name",...) is called multiple times
(e.g. before login and after login), the successive calls will reuse the
previously allocated JS object and allocated private data memory. However, the
private data memory (which includes the descriptor of an open user.dat file,
if it has been opened), was always zeroed, even if it was being reused. This
would leak open file descriptor.

So any (pre)login scripts or web scripts that use the "user" object (which
is all zeroed-out before login) and then allows a user to subsequently login,
would leak a file descriptor.
parent 27e3468a
......@@ -1632,11 +1632,11 @@ JSObject* js_CreateUserObject(JSContext* cx, JSObject* parent, scfg_t* cfg, char
if(userobj==NULL)
return(NULL);
if((p=JS_GetPrivate(cx, userobj)) == NULL) /* Uses existing private pointer: Fix memory leak? */
if((p=JS_GetPrivate(cx, userobj)) == NULL) { /* Uses existing private pointer: Fix memory leak? */
if((p=(private_t*)malloc(sizeof(private_t)))==NULL)
return(NULL);
memset(p,0,sizeof(private_t));
memset(p,0,sizeof(private_t));
}
p->client = client;
p->cached = FALSE;
......
  • Great!.. This could be related to several reports that other users mention regarding errors of too many open files, true?

  • True, this appears to fix "the leak" of user.dat file descriptors.

Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment