Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

memory leak at CTinyJS::factor() #6

Open
GoogleCodeExporter opened this issue Mar 24, 2015 · 5 comments
Open

memory leak at CTinyJS::factor() #6

GoogleCodeExporter opened this issue Mar 24, 2015 · 5 comments

Comments

@GoogleCodeExporter
Copy link

try {
  /* JSON-style object definition */
  l->match('{');
  while (l->tk != '}') {
    string id = l->tkStr;
    // we only allow strings or IDs on the left hand side of an initialisation
    if (l->tk==LEX_STR) l->match(LEX_STR);
    else l->match(LEX_ID);
    l->match(':');
    CScriptVarSmartLink a = assignment(execute);
    if (execute) {
      contents->addChild(id, a->var);
    }
    // no need to clean here, as it will definitely be used
    if (l->tk != '}') l->match(',');
  }

  l->match('}');
} catch (CScriptException *e) {
  delete contents;
  throw e;
}

Original issue reported on code.google.com by zhoujr.m...@gmail.com on 27 Dec 2011 at 10:14

@GoogleCodeExporter
Copy link
Author

Any other information?
Where is the leak? What code do you run that produces the leak?
Does this bit of code fix the problem?

Original comment by pur3m...@googlemail.com on 29 Dec 2011 at 3:42

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

When a CScriptException throwed at match function, the memory allocated to 
'contents' can not be freed.

And I found several memory leak on catch statement, because the catched 
exception is not freed yet.

Please see blow statements.

try {
  throw new CScriptException("one");
}
catch (CScriptException* e) {
  throw new CScriptException("other");
}

Hope for your reply.Thanks.

Original comment by zhoujr.m...@gmail.com on 29 Dec 2011 at 4:56

@GoogleCodeExporter
Copy link
Author

Hi, Thanks for your information.

This is definitely a problem, and we could hopefully solve it be surrounding 
each call in the interpreter with a try...finally. 

However at the moment I feel this is very low priority - exceptions should be 
just that - an exception, so if a program is running correctly, then there 
should be no memory leaks.

Original comment by pur3m...@googlemail.com on 5 Jan 2012 at 3:02

  • Changed state: Accepted
  • Added labels: Priority-Low
  • Removed labels: Priority-Medium

@GoogleCodeExporter
Copy link
Author

Yes. So it is. I am working on Symbian platform, and a little memory leak can 
not be tolerated.

Original comment by zhoujr.m...@gmail.com on 6 Jan 2012 at 1:54

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant