www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - free causes exception

reply Igor <Vladamir.I google.com> writes:
I have successfully malloc'ed an object but when I go to free it 
in the destructor I get an exception. The destructor simply has

~this() // destructor for Foo
{
     core.stdc.stdlib.free(&this);
}


auto buffer = core.stdc.stdlib.malloc(__traits(classInstanceSize, 
App))[0..__traits(classInstanceSize, App)];
auto app = cast(App)emplace!App(buffer[]);

I tried to retain a ptr to buffer and free that but still no 
good. I also get a depreciation warning that &this is not an 
lvalue. Hopefully I don't have to keep a ptr around to this 
simply to free it and avoid future issues?

So how am I suppose to free an object?
Jan 26
next sibling parent reply Daniel Kozak via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
V Tue, 26 Jan 2016 14:20:29 +0000
Igor via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
napsáno:

 I have successfully malloc'ed an object but when I go to free it 
 in the destructor I get an exception. The destructor simply has
 
 ~this() // destructor for Foo
 {
      core.stdc.stdlib.free(&this);
 }
 
 
 auto buffer = core.stdc.stdlib.malloc(__traits(classInstanceSize, 
 App))[0..__traits(classInstanceSize, App)];
 auto app = cast(App)emplace!App(buffer[]);
 
 I tried to retain a ptr to buffer and free that but still no 
 good. I also get a depreciation warning that &this is not an 
 lvalue. Hopefully I don't have to keep a ptr around to this 
 simply to free it and avoid future issues?
 
 So how am I suppose to free an object?
 
 
core.stdc.stdlib.free(cast(void *)this);
Jan 26
parent reply Igor <Vladamir.I google.com> writes:
On Tuesday, 26 January 2016 at 14:48:48 UTC, Daniel Kozak wrote:
 V Tue, 26 Jan 2016 14:20:29 +0000
 Igor via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
 napsáno:

 [...]
core.stdc.stdlib.free(cast(void *)this);
I still get an exception: Exception thrown at 0x00007FF6C7CA3700 in test.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
Jan 26
parent Daniel Kozak via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
V Tue, 26 Jan 2016 15:24:00 +0000
Igor via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
napsáno:

 On Tuesday, 26 January 2016 at 14:48:48 UTC, Daniel Kozak wrote:
 V Tue, 26 Jan 2016 14:20:29 +0000
 Igor via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
 napsáno:
  
 [...]  
core.stdc.stdlib.free(cast(void *)this);
I still get an exception: Exception thrown at 0x00007FF6C7CA3700 in test.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
Can you post full code?
Jan 26
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 01/26/2016 06:20 AM, Igor wrote:
 I have successfully malloc'ed an object but when I go to free it in the
 destructor I get an exception. The destructor simply has

 ~this() // destructor for Foo
 {
      core.stdc.stdlib.free(&this);
 }
That design suggests a complexity regarding object responsibilities: Assuming that the object was constructed on a piece of memory that it did *not* allocate, the memory was owned by somebody else. In that case and in general, freeing the memory should be the responsibility of that other somebody as well. Even if it is acceptable, you must also make sure that opAssign() and post-blit do the right thing: no two object should own the same piece of memory. Ali
Jan 26
parent reply Igor <Vladamir.I google.com> writes:
On Tuesday, 26 January 2016 at 19:34:22 UTC, Ali Çehreli wrote:
 On 01/26/2016 06:20 AM, Igor wrote:
 I have successfully malloc'ed an object but when I go to free
it in the
 destructor I get an exception. The destructor simply has

 ~this() // destructor for Foo
 {
      core.stdc.stdlib.free(&this);
 }
That design suggests a complexity regarding object responsibilities: Assuming that the object was constructed on a piece of memory that it did *not* allocate, the memory was owned by somebody else. In that case and in general, freeing the memory should be the responsibility of that other somebody as well. Even if it is acceptable, you must also make sure that opAssign() and post-blit do the right thing: no two object should own the same piece of memory. Ali
That shouldn't be the case. I allocate in a static method called New once. I then deallocate in the destructor. Basically just as one would do in C++. I'm not sure about opAssign and post-blit class Foo { ~this() // destructor for Foo { core.stdc.stdlib.free(cast(void *)this); } // Creates a Foo static public Foo New() { auto buffer = core.stdc.stdlib.malloc(__traits(classInstanceSize, Foo))[0..__traits(classInstanceSize, Foo)]; auto app = cast(Foo)emplace!Foo(buffer[]); } } hence auto f = Foo.New(); then .destroy(f); which is where the crash happens. If I don't destroy, it works fine + memory leak.
Jan 26
next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 01/26/2016 01:21 PM, Igor wrote:

 I allocate in a static method called New once. I then deallocate in the
 destructor. Basically just as one would do in C++.
I would never do that in even C++. I don't know any C++ idiom that warrants 'delete this' where superior alternatives cannot be used.
 class Foo
 {
      ~this() // destructor for Foo
      {
          core.stdc.stdlib.free(cast(void *)this);
      }

          // Creates a Foo
      static public Foo New()
      {
          auto buffer =
 core.stdc.stdlib.malloc(__traits(classInstanceSize,
 Foo))[0..__traits(classInstanceSize, Foo)];
          auto app = cast(Foo)emplace!Foo(buffer[]);
          }
 }

 hence

 auto f = Foo.New();

 then .destroy(f);
Something else in the program must have something to do with it. I don't see the crash with the following program: import std.stdio; import core.stdc.stdlib; import std.conv; class Foo { ~this() // destructor for Foo { core.stdc.stdlib.free(cast(void *)this); } // Creates a Foo static public Foo New() { auto buffer = core.stdc.stdlib.malloc( __traits(classInstanceSize, Foo)) [0..__traits(classInstanceSize, Foo)]; auto app = cast(Foo)emplace!Foo(buffer[]); return app; } } void main() { auto f = Foo.New(); .destroy(f); } Ali
Jan 26
prev sibling parent Kagamin <spam here.lot> writes:
On Tuesday, 26 January 2016 at 21:21:29 UTC, Igor wrote:
 That shouldn't be the case. I allocate in a static method 
 called New once. I then deallocate in the destructor. Basically 
 just as one would do in C++.
You can't deallocate in destructor in C++, because an object can be embedded in another object, so if it's destructor deallocates itself, it will deallocate the container object before it finishes its destruction. It's delete operator that deallocates memory in C++.
Jan 27
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/26/16 9:20 AM, Igor wrote:
 I have successfully malloc'ed an object but when I go to free it in the
 destructor I get an exception. The destructor simply has

 ~this() // destructor for Foo
 {
      core.stdc.stdlib.free(&this);
 }


 auto buffer = core.stdc.stdlib.malloc(__traits(classInstanceSize,
 App))[0..__traits(classInstanceSize, App)];
 auto app = cast(App)emplace!App(buffer[]);

 I tried to retain a ptr to buffer and free that but still no good. I
 also get a depreciation warning that &this is not an lvalue. Hopefully I
 don't have to keep a ptr around to this simply to free it and avoid
 future issues?

 So how am I suppose to free an object?
Don't do it in the destructor. I can only imagine that you are triggering the destructor with destroy? In this case, destroy is calling the destructor, but then tries to zero the memory (which has already been freed). There is a mechanism D supports (but I believe is deprecated) by overriding new and delete. You may want to try that. It's deprecated, but has been for years and years, and I doubt it's going away any time soon. A class shouldn't care how it's allocated or destroyed. That is for the memory manager to worry about. -Steve
Jan 26
parent reply Igor <Vladamir.I google.com> writes:
On Tuesday, 26 January 2016 at 20:17:20 UTC, Steven Schveighoffer 
wrote:
 On 1/26/16 9:20 AM, Igor wrote:
 I have successfully malloc'ed an object but when I go to free 
 it in the
 destructor I get an exception. The destructor simply has

 ~this() // destructor for Foo
 {
      core.stdc.stdlib.free(&this);
 }


 auto buffer = 
 core.stdc.stdlib.malloc(__traits(classInstanceSize,
 App))[0..__traits(classInstanceSize, App)];
 auto app = cast(App)emplace!App(buffer[]);

 I tried to retain a ptr to buffer and free that but still no 
 good. I
 also get a depreciation warning that &this is not an lvalue. 
 Hopefully I
 don't have to keep a ptr around to this simply to free it and 
 avoid
 future issues?

 So how am I suppose to free an object?
Don't do it in the destructor. I can only imagine that you are triggering the destructor with destroy? In this case, destroy is calling the destructor, but then tries to zero the memory (which has already been freed). There is a mechanism D supports (but I believe is deprecated) by overriding new and delete. You may want to try that. It's deprecated, but has been for years and years, and I doubt it's going away any time soon. A class shouldn't care how it's allocated or destroyed. That is for the memory manager to worry about.
um? Memory manager? I am doing it manually C++ style so I don't have to worry about the god forsaken memory manager. Why is it so difficult? I create the object and release it when I need to. I can replace the destroy(f) with free(inline the code) but I don't see why that should matter. The whole point of destructors is to do this sort of stuff. That's why they were invented in the first place!?!
Jan 26
next sibling parent ZombineDev <valid_email he.re> writes:
On Tuesday, 26 January 2016 at 21:23:28 UTC, Igor wrote:
 On Tuesday, 26 January 2016 at 20:17:20 UTC, Steven 
 Schveighoffer wrote:
 On 1/26/16 9:20 AM, Igor wrote:
 I have successfully malloc'ed an object but when I go to free 
 it in the
 destructor I get an exception. The destructor simply has

 ~this() // destructor for Foo
 {
      core.stdc.stdlib.free(&this);
 }


 auto buffer = 
 core.stdc.stdlib.malloc(__traits(classInstanceSize,
 App))[0..__traits(classInstanceSize, App)];
 auto app = cast(App)emplace!App(buffer[]);

 I tried to retain a ptr to buffer and free that but still no 
 good. I
 also get a depreciation warning that &this is not an lvalue. 
 Hopefully I
 don't have to keep a ptr around to this simply to free it and 
 avoid
 future issues?

 So how am I suppose to free an object?
Don't do it in the destructor. I can only imagine that you are triggering the destructor with destroy? In this case, destroy is calling the destructor, but then tries to zero the memory (which has already been freed). There is a mechanism D supports (but I believe is deprecated) by overriding new and delete. You may want to try that. It's deprecated, but has been for years and years, and I doubt it's going away any time soon. A class shouldn't care how it's allocated or destroyed. That is for the memory manager to worry about.
um? Memory manager? I am doing it manually C++ style so I don't have to worry about the god forsaken memory manager. Why is it so difficult? I create the object and release it when I need to. I can replace the destroy(f) with free(inline the code) but I don't see why that should matter. The whole point of destructors is to do this sort of stuff. That's why they were invented in the first place!?!
Why not simply: class Foo { this(Arg1, Arg2) { ... } ... } // Option A: import std.typecons : scoped; auto foo = scoped!Foo(arg1, arg2); // Option B: import std.experimental.allocator : make, dispose; import std.experimental.allocator.mallocator; auto foo = Mallocator.instance.make!Foo(arg1, arg2); scope(exit) Mallocator.instance.dispose(foo); http://dlang.org/phobos/std_typecons#.scoped http://dlang.org/phobos/std_experimental_allocator
Jan 26
prev sibling next sibling parent ZombineDev <valid_email he.re> writes:
On Tuesday, 26 January 2016 at 21:23:28 UTC, Igor wrote:
 On Tuesday, 26 January 2016 at 20:17:20 UTC, Steven 
 Schveighoffer wrote:
 On 1/26/16 9:20 AM, Igor wrote:
 [...]
Don't do it in the destructor. I can only imagine that you are triggering the destructor with destroy? In this case, destroy is calling the destructor, but then tries to zero the memory (which has already been freed). There is a mechanism D supports (but I believe is deprecated) by overriding new and delete. You may want to try that. It's deprecated, but has been for years and years, and I doubt it's going away any time soon. A class shouldn't care how it's allocated or destroyed. That is for the memory manager to worry about.
um? Memory manager? I am doing it manually C++ style so I don't have to worry about the god forsaken memory manager. Why is it so difficult? I create the object and release it when I need to. I can replace the destroy(f) with free(inline the code) but I don't see why that should matter. The whole point of destructors is to do this sort of stuff. That's why they were invented in the first place!?!
Destructors are meant to destroy the members of the object, not the object itself. An object should be freed by the destructor of its owner and so on, transitively. A class should not have a hard coded dependency on malloc/free, or the GC. You should strive to design it in such a way that the clients of the class are free to decide how to manage its memory.
Jan 26
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 26 January 2016 at 21:23:28 UTC, Igor wrote:

 um? Memory manager? I am doing it manually C++ style so I don't 
 have to worry about the god forsaken memory manager. Why is it 
 so difficult? I create the object and release it when I need to.
He's talking about *your* memory manager, whatever system you have set up to allocate and deallocate memory.
 I can replace the destroy(f) with free(inline the code) but I 
 don't see why that should matter. The whole point of 
 destructors is to do this sort of stuff. That's why they were 
 invented in the first place!?!
Not in D! You have to get your mind out of C++ mode when programming in D. D is not C++, no matter how similar they are, and there are idioms that work well in C++ that do not work in D. There are cases where D's destructors behave like those in C++, but not always. Since this approach is failing for you, I suggest you make a function or template that can take any object you've manually allocated, call destroy on it, then deallocate it. The destructor can still clean up any resources the object maintains, but the responsibility for deallocating the object will be taken out of the destructor. It also ensures that deallocation does not interfere with the operation of destroy.
Jan 26
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/26/16 4:23 PM, Igor wrote:
 On Tuesday, 26 January 2016 at 20:17:20 UTC, Steven Schveighoffer wrote:
 On 1/26/16 9:20 AM, Igor wrote:
 I have successfully malloc'ed an object but when I go to free it in the
 destructor I get an exception. The destructor simply has

 ~this() // destructor for Foo
 {
      core.stdc.stdlib.free(&this);
 }


 auto buffer = core.stdc.stdlib.malloc(__traits(classInstanceSize,
 App))[0..__traits(classInstanceSize, App)];
 auto app = cast(App)emplace!App(buffer[]);

 I tried to retain a ptr to buffer and free that but still no good. I
 also get a depreciation warning that &this is not an lvalue. Hopefully I
 don't have to keep a ptr around to this simply to free it and avoid
 future issues?

 So how am I suppose to free an object?
Don't do it in the destructor. I can only imagine that you are triggering the destructor with destroy? In this case, destroy is calling the destructor, but then tries to zero the memory (which has already been freed). There is a mechanism D supports (but I believe is deprecated) by overriding new and delete. You may want to try that. It's deprecated, but has been for years and years, and I doubt it's going away any time soon. A class shouldn't care how it's allocated or destroyed. That is for the memory manager to worry about.
um? Memory manager? I am doing it manually C++ style so I don't have to worry about the god forsaken memory manager. Why is it so difficult? I create the object and release it when I need to.
As Mike said, I mean whatever you are using for memory management. The class is not responsible for allocating or deallocating itself, just initializing itself and deinitializing itself. So if you use malloc and free, that is your memory manager.
 I can replace the destroy(f) with free(inline the code) but I don't see
 why that should matter. The whole point of destructors is to do this
 sort of stuff. That's why they were invented in the first place!?!
It isn't even this way in C++. No destructors deallocate 'this'. All D destructors should destroy all the members. And generally speaking, if you ever plan to use a class with the GC, you should only destroy non-GC members. The GC members may already be destroyed. -Steve
Jan 27
parent reply Igor <Vladamir.I google.com> writes:
On Wednesday, 27 January 2016 at 14:31:20 UTC, Steven 
Schveighoffer wrote:
 On 1/26/16 4:23 PM, Igor wrote:
 On Tuesday, 26 January 2016 at 20:17:20 UTC, Steven 
 Schveighoffer wrote:
 [...]
um? Memory manager? I am doing it manually C++ style so I don't have to worry about the god forsaken memory manager. Why is it so difficult? I create the object and release it when I need to.
As Mike said, I mean whatever you are using for memory management. The class is not responsible for allocating or deallocating itself, just initializing itself and deinitializing itself. So if you use malloc and free, that is your memory manager.
 I can replace the destroy(f) with free(inline the code) but I 
 don't see
 why that should matter. The whole point of destructors is to 
 do this
 sort of stuff. That's why they were invented in the first 
 place!?!
It isn't even this way in C++. No destructors deallocate 'this'. All D destructors should destroy all the members. And generally speaking, if you ever plan to use a class with the GC, you should only destroy non-GC members. The GC members may already be destroyed. -Steve
There needs to be better docs on this? Or at least someone needs to provide a link! ;) Why can there be an "deplace" equivalent to emplace? Everone says it's so easy not to use the GC in D yet I can't seem to find any real world examples ;/
Jan 27
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/27/16 5:35 PM, Igor wrote:
 On Wednesday, 27 January 2016 at 14:31:20 UTC, Steven Schveighoffer wrote:
 All D destructors should destroy all the members. And generally
 speaking, if you ever plan to use a class with the GC, you should only
 destroy non-GC members. The GC members may already be destroyed.
BTW, I wrote that wrong, I should have said "All D destructors *should do is* destroy all the members." In other words, you shouldn't do anything but destroy members.
 There needs to be better docs on this? Or at least someone needs to
 provide a link! ;)
http://dlang.org/spec/class.html#destructors "Furthermore, the order in which the garbage collector calls destructors for unreference objects is not specified. This means that when the garbage collector calls a destructor for an object of a class that has members that are references to garbage collected objects, those references may no longer be valid. **This means that destructors cannot reference sub objects.**" (emphasis mine)
 Why can there be an "deplace" equivalent to emplace?
emplace is not responsible for allocation, it just does all the necessary things to place an object inside memory you provide (wherever it came from), and call the proper constructor. The opposite of emplace is destroy. This calls the destructor and resets the class to a "destroyed" state (so calling destroy on a class a second time will not call the destructor again).
 Everone says it's so easy not to use the GC in D yet I can't seem to
 find any real world examples ;/
The easiness of doing it is a judgment call. However, it is possible. I'm sure there are examples out there, but I'm not well versed in where to find them. -Steve
Jan 27