#43 sq_close crashes the application if not all Sqrat::Object instances have destructed


I may be getting a little ahead of myself here as I have not written a minimal example to showcase the problem. However, I know that Sqrat::Function and Sqrat::Table crashes my application if not all of them have destructed when sq_close is called. I'm wondering if this is something that Sqrat should handle or if it should be handled by the user. It is really annoying to get a random segmentation fault and have to find out that it is a limitation of Sqrat causing it. However, Sqrat would have to keep track of all objects it has created in some sort of container to remedy this. Any thoughts?

This post is what prompted this question:


  • Wizzard

    Wizzard - 2013-09-26
    • status: open --> pending
    • assigned_to: Wizzard
    • Group: -->
  • Andy Tai

    Andy Tai - 2013-10-06

    Hmmm.. at first thought I think Sqrat should manage the objects it created. that should be the expectation of the majority of users that Sqrat does as much work as it can for the user...I guess. If we leave to the user to handle it, that seems to be inconvenience for the user in many contexts..

    Alternatively we can support both with different constructors or arguments to control which mechanism to use, default to Sqrat controlling the cleanup, and make the user clearly aware of which choice he makes and the consequences. Is that good approach?

  • Wizzard

    Wizzard - 2013-10-07

    I don't think that an alternative is necessary. How do we go about injecting code to happen before sq_close is called? Do we need to force users to call Sqrat::VM::Close (or an equivalent function) or is there a better way?

    Last edit: Wizzard 2013-10-07
  • Andy Tai

    Andy Tai - 2013-10-17

    added a test case for this scenario:

    HSQUIRRELVM v = sq_open(1024);
    Table table(v);
    RootTable(v).Bind(_SC("tb"), table);

    // do something with the table tb

    sq_close(v); // see what happens now


  • Andy Tai

    Andy Tai - 2013-10-18

    Sqrat::VM is not a class that the user needs to use, as in the above test case.

  • Andy Tai

    Andy Tai - 2013-10-18

    I am not sure if it is a good requirement that the user should call Sqrat::Object::Release() ... or Sqrat needs to track all Sqrat::Object in a VM

    Last edit: Andy Tai 2013-10-18
  • Wizzard

    Wizzard - 2013-10-19

    Do we document that all Sqrat::Object must be destroyed before sq_close is called or do we actually fix it?

    Edit: There is no way to fix it without requiring the user to call Sqrat::Close or an equivalent function. This is Squirrel's fault.
    Leave this issue open until we document the limitation

    Last edit: Wizzard 2013-10-19
  • leanid chaika

    leanid chaika - 2014-01-25

    Please let me say about example.
    It is very strange to call sq_close before destrow all Sqrat objects. It looks like programmer error, just add some text about it in documentation and please do not add something like "or Sqrat needs to track all Sqrat::Object in a VM"

  • Wizzard

    Wizzard - 2014-06-07
    • status: pending --> closed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks