It would be great if you could submit a bug report with complete source (both C++ and chaiscript) that demonstrate the memory leak so we can check into it.

Thanks.
Jason

class GlobalVariableHelper
{
public:
  Boxed_Value & __get_global(std::string const & name)
  {
    // require read-lock for thread-safe
    return _M_globalvars[name];
  }
 
  void __set_global(std::string const & name, Boxed_Value & value)
  {
    // require write-lock for thread-safe
    __globalvars[name] = value;
  }
 
private:
  std::map< std::string, Boxed_Value > _M_globalvars;
}
 
...
GlobalVariableHelper gvhelper;
chai.add(fun(&GlobalVariableHelper::__get_global, gvhelper), "get_global");
chai.add(fun(&GlobalVariableHelper::__set_global, gvhelper), "set_global");

and in chaiscript:

set_global("foo", 100); // foo = 100;
set_global("foo", get_global("foo") + 10); // foo += 10

Thanks, that works so far.

My new problem, taking the code from above as base:

chaiscript::ChaiScript::State backupState;
void init()
{
	Chai.add(fun<void (Class2 *)>(&Class2::Print1), "Print1");
	Chai.add(fun(&Class2::Print2), "Print2");
	Chai.add(fun(&getClass2),"get");
        backupState = Chai.get_state()
}
 
void ResetState()
{
	Chai.set_state(backupState);
}

User Input: "var i = 3"
Call : ResetState()
User Input: "return i" - returns 3

I would have expected "i" to not exist anymore.

Then i tryed the following:

chaiscript::ChaiScript pChai = new chaiscript::ChaiScript;
...
...
...
void ResetState()
{
        delete pChai;
        pChai = new chaiscript::ChaiScript;
	pChai->set_state(backupState);
}

That will throw an exeption as soon ResetState() is called.

Edit:

I read your statement about avoiding global vars and using functions instead. That makes perfectly sense and everything is working as intended now, as functions are reset properly.

Edit 2:

I found a memory leak

void ResetState()
{
	pChai->set_state(backupState);
        pChai->add(fun(&getClass2),"get");
}
 
PseudoMain()
{
    	while(command != "quit")
	{
		for(int i = 0; i < 200; i++)  // just a little bit extra overhead
			pChai.ResetState();
 
		if(command == "gc")
			pChai.RunFile("Test.chai");
		command = get_next_command();
 
}

What happens?

case 1: if calling eval EVERY loop, memory usage is low, nothing is leaking

case 2: if calling eval NEVER , memory usage keeps raising, here is the leak.

case 3: if calling eval CONSTANTLY each 10th loop, memory usage is higher than in case1, but seems not to leak any further

case 4: get´s complicated to explain. each time, ResetState() is Called without calling eval afterwards, memory usage will go up.
for example after 10 times ResetState(), i am calling RunFile() or whatever involves eval. After this eval, i can again call ResetState() 10 times, without increasing the memory usage. but as soon as it get´s called the 11th..... time without eval intetween memory usage will go up again.

commenting out either the set_state or add will stop this strange behaviour. but will also break my way of updating important pointers.
I solved it, by calling eval("") at the end of my Reset function.
But it doesn´t feel like beeing the proper solution...

var foo = 100
def barfunc()
{
  print(foo)
}
print(foo) // prints "100"
barfunc() // Eval_error, Can not find object: foo.

shouldn't `foo` be a global variable that can be resolved inside barfunc(), so calling barfunc() prints "100", too?

is this the intended behavior?

I really would have expected your example to work. It seems I'm wrong, however.

You can force the issue by telling ChaiScript exactly what type you want to work with:

class Class1
{
public:
	Class1(){}
	virtual ~Class1(){};
	void Print1(){std::cout << "Print from Class1" << std::endl;}
};
 
class Class2 : public Class1
{
public:
	Class2(){}
	virtual ~Class2(){}
	void Print2(){std::cout << "Print from Class2" << std::endl;}
};
 
Class2 * pClass2 = new Class2;
 
Class2 * getClass2(void)
{
	return pClass2;
}
 
void init()
{
	Chai.add(fun<void (Class2 *)>(&Class2::Print1), "Print1");
	Chai.add(fun(&Class2::Print2), "Print2");
	Chai.add(fun(&getClass2),"get");
}

You seem to be bubbling up the question of handling derived types, something that we have avoided up until now. We'll see what's possible.

-Jason

I'll look into it this evening, not sure why you would have a problem with that one.

Your error is something of a red herring, the actual problem is that the local variables for an object type and the parameter names for the constructor are conflicting.

var kPI = 3.141592653589793
var kSolarMass = 4.0 * kPI * kPI
var kDaysPerYear = 365.24
var dt = 0.01
 
attr Vector3::x
attr Vector3::y
attr Vector3::z
def Vector3::Vector3(m_x, m_y, m_z) {
    this.x = m_x
    this.y = m_y
    this.z = m_z
}
 
def Vector3::`+`(rhs) {
    return Vector3(this.x + rhs.x, this.y + rhs.y, this.z + rhs.z)
}
 
def Vector3::`-`(rhs) {
    return Vector3(this.x - rhs.x, this.y - rhs.y, this.z - rhs.z)
}
 
def Vector3::`*`(rhs) {
    return Vector3(this.x * rhs, this.y * rhs, this.z * rhs)
}
 
def Vector3::Length() {
    return sqrt(this.x * this.x + this.y * this.y + this.z * this.z)
}
 
def Vector3::SquaredLength() {
    return (this.x * this.x + this.y * this.y + this.z * this.z)
}
 
attr Body::position
attr Body::velocity
attr Body::mass
def Body::Body() { }
def Body::Body(m_x, m_y, m_z, m_vx, m_vy, m_vz, m_mass) {
    this.position = Vector3(m_x, m_y, m_z)
    this.velocity = Vector3(m_vx, m_vy, m_vz)
    this.mass = m_mass
}
 
var sun = Body(0, 0, 0, 0, 0, 0, kSolarMass)

The above should work for you. We will see about fixing the scope problem so that this lookup/naming problem doesn't catch other people, (and should probably fix that error you are getting, to something more reasonable too).

I'll look into the IRC channel, might be hard for the main developers to keep up with, but we'll see if we can't give it a shot.

-Jason

This one is fixed too, in the newly released 2.3.2.

Thanks.

As I said though, you could've kept the specialization by simply marking it as inline. That would stop the linker errors.

Why did you decide to instead pull the specialization? I'm not questioning your decision, as obviously you're the expert when it comes to the implementation of ChaiScript, I'm just curious..

You're getting outside of my knowledge for windows programming, so I'm something at a loss a to how to help you with this one, unless you can provide a succinct example to reproduce the problem.

That said however, I'm guessing that your problems stem from our automatic thread context handling which is based on a static thread local storage objects.

If that's the case, you may be able to work around it by compiling with CHAISCRIPT_NO_THREADS, which I'm guessing IS an option for you, since you had swapped lua out for ChaiScript.

Let me know if this helps at all.

Hey, I think I have indeed found another issue with ChaiScript (unless I'm missing something).

My project makes use of quite a few DLLs, and about 3 of those DLLs need to have access to ChaiScript. Previously when I was using Lua and LuaBind in a similar situation, I simply passed around a pointer to the LuaBind instance (or rather, a class containing that instance, along with some extra data).

However, when I try to do that with ChaiScript I'm getting some very nasty access violations.

The problem manifests itself in two situations:
1. When I use a global ChaiScript object (i.e. static) that is NOT function local. The reason it matters whether it's function local is that the problem seems to manifest itself when the object is created "too early". The problem manifests itself when ChaiScript is created too early, I don't know what "too early" exactly is, I just know that if I defer creation of the ChaiScript object until first use, there is no problem. I can do this by either using a pointer to the ChaiScript instance and allocating it at first use, or using a local static instance.

2. Above, I noted that if I allocate the ChaiScript instance at first use, then the problem goes away. This is true, but only if the module using the object is the one that allocated it. As soon as I give the pointer to another module to use, I get the access violation again. I am compiling all modules with the same settings, so that should not be an issue, and that worked fine when I used to use LuaBind...

I'm happy to provide more information and sample code if necessary. Right now I have no idea what's going on.

Also, I should mention, the two errors I outlined above are fairly minor. This one however is critical. If I can't work out how to fix this I don't think I'm going to be able to use ChaiScript, which would be extremely unfortunate as I've grown quite accustomed to it in my (albeit short) use of it. So, help with this matter would be greatly appreciated.

Thanks.

P.S. I don't know whether this is relevant, but if you're trying to reproduce this error, you may need to know that my DLLs are not loaded 'normally'. They are 'injected' into another application. This in itself should not cause any issues though, because I'm making sure to do it safely. (I'm avoiding any potential problems which may be caused by doing anything dangerous in DllMain, by doing NOTHING in DLLMain, and opting instead to use a named export which is called once the module is fully loaded, hence making it safe to allocate any resources I want/need.)