Re: InvalidMemoryOperationError when calling functions from destructors
Further inspection suggests that the BetaClass object I was accessing was already finalized by the time the AlphaClass object got around to trying to mess with it. Conclusion is that whether it's the in-destructor access or not, it's simply not safe to try to clean things up this way. I think I have a safer alternative. What was interesting is that even after the BetaClass object has been cleaned up, I can access any variables it may have contained. If, for example, it has an integer value that's publicly visible, I can still read that.(haven't tried writing.)
InvalidMemoryOperationError when calling functions from destructors
I've run into a problem which I'd like to hope is a bug, but
let's see if we can figure out if I'm doing something stupid
first, eh?
When a destructor calls a function from another module, I get an
InvalidMemoryOperationError. When a destructor calls a function
from another class in the same module, and that function calls
the function I was trying to call initially, everything seems to
go fine. When a destructor calls a function in the same class,
which calls a function in a different module, I get the
InvalidMemoryOperationError again.
This may have to do with garbage collector subtleties I'm not
familiar with.
Example:
File alpha.d
module alpha;
import beta;
class AlphaClass
{
BetaClass bc;
Alpha2Class a2c;
void cleanup()
{
bc.cleanup();//if this is called from the destructor,
expect an error.
}
public:
this()
{
bc = new BetaClass();
a2c = new Alpha2Class(bc);
}
~this
{
bc.cleanup();//this will cause an error.
a2c.cleanup();//this works fine
cleanup();//this will cause an error.
}
}
class Alpha2Class
{
BetaClass bc;
void cleanup()
{
bc.cleanup();
}
public:
this(BetaClass initbc)
{
bc = initbc;
}
}
File beta.d
module beta;
class BetaClass
{
public:
this()
{
//do something
}
void cleanup()
{
//clean up after the bosses
}
}
Further info can be provided if necessary.
Re: InvalidMemoryOperationError when calling functions from destructors
On Thursday, 25 April 2013 at 16:00:31 UTC, Vladimir Panteleev wrote: On Thursday, 25 April 2013 at 15:50:27 UTC, Volfram wrote: Further info can be provided if necessary. Can you provide a full program that exhibits the behavior, or at least a stack trace? You may need to recompile Phobos and Druntime with the -gs flag to enable correct stacktraces. Well I've got a 6000-line hackeneyed game engine in progress built using the kind of logic that usually only I can follow, but I somehow don't think that's what you're after. Jacob Carlborg: I thought it might be something like that, which is part of the reason I didn't post this in bug reports. I'll figure out something else. Thanks.
