Re: how to debug memory errors

2016-11-08 Thread bachmeier via Digitalmars-d-learn
On Tuesday, 8 November 2016 at 14:55:53 UTC, Steven Schveighoffer wrote: Indeed, you should not. I'm saying this type of error can explain the observed behavior. The original post I responded to said "I don't know if the double free problem is related to this." -Steve Okay. I thought

Re: how to debug memory errors

2016-11-08 Thread Steven Schveighoffer via Digitalmars-d-learn
On 11/8/16 6:26 AM, bachmeier wrote: On Monday, 7 November 2016 at 02:22:35 UTC, Steven Schveighoffer wrote: Imagine a resource wrapper like so: class Foo { int *mem; this() { mem = cast(int *)malloc(int.sizeof); } ~this() { .free(mem); } } Now, you have a problem if you do something

Re: how to debug memory errors

2016-11-08 Thread bachmeier via Digitalmars-d-learn
On Tuesday, 8 November 2016 at 11:53:37 UTC, Era Scarecrow wrote: On Tuesday, 8 November 2016 at 11:26:55 UTC, bachmeier wrote: Is there a valid use case for something like this? Why would you want to do anything inside ~this with GC memory? If we assume it's a C++

Re: how to debug memory errors

2016-11-08 Thread Era Scarecrow via Digitalmars-d-learn
On Tuesday, 8 November 2016 at 11:26:55 UTC, bachmeier wrote: Is there a valid use case for something like this? Why would you want to do anything inside ~this with GC memory? If we assume it's a C++ attachment/library/object using different memory allocation?

Re: how to debug memory errors

2016-11-08 Thread bachmeier via Digitalmars-d-learn
On Monday, 7 November 2016 at 02:22:35 UTC, Steven Schveighoffer wrote: Imagine a resource wrapper like so: class Foo { int *mem; this() { mem = cast(int *)malloc(int.sizeof); } ~this() { .free(mem); } } Now, you have a problem if you do something like this: class Bar { Foo foo;

Re: how to debug memory errors

2016-11-08 Thread Lodovico Giaretta via Digitalmars-d-learn
On Tuesday, 8 November 2016 at 07:39:12 UTC, Era Scarecrow wrote: On Tuesday, 8 November 2016 at 06:04:59 UTC, thedeemon wrote: On Tuesday, 8 November 2016 at 05:36:22 UTC, Era Scarecrow wrote: Hmmm.. I had the impression that if something was referenced by another object, then it couldn't

Re: how to debug memory errors

2016-11-07 Thread Era Scarecrow via Digitalmars-d-learn
On Tuesday, 8 November 2016 at 06:04:59 UTC, thedeemon wrote: On Tuesday, 8 November 2016 at 05:36:22 UTC, Era Scarecrow wrote: Hmmm.. I had the impression that if something was referenced by another object, then it couldn't be collected, Another *live* object, I.e. reachable from globals

Re: how to debug memory errors

2016-11-07 Thread thedeemon via Digitalmars-d-learn
On Tuesday, 8 November 2016 at 05:36:22 UTC, Era Scarecrow wrote: Hmmm.. I had the impression that if something was referenced by another object, then it couldn't be collected, Another *live* object, i.e. reachable from globals and stack. If you have a big tree and it becomes unreachable

Re: how to debug memory errors

2016-11-07 Thread Era Scarecrow via Digitalmars-d-learn
On Tuesday, 8 November 2016 at 03:27:32 UTC, Steven Schveighoffer wrote: Err that makes no sense... If that's the case why have a destructor at all? To free non-GC resources. http://dlang.org/spec/class.html#destructors "Furthermore, the order in which the garbage collector calls

Re: how to debug memory errors

2016-11-07 Thread Steven Schveighoffer via Digitalmars-d-learn
On 11/6/16 11:01 PM, thedeemon wrote: On Monday, 7 November 2016 at 02:22:35 UTC, Steven Schveighoffer wrote: OP: it's not legal to destroy or even access GC allocated members in a destructor. The GC may have already destroyed that data. Isn't destroy() fine there? It doesn't call destructors

Re: how to debug memory errors

2016-11-07 Thread Steven Schveighoffer via Digitalmars-d-learn
On 11/6/16 10:57 PM, Era Scarecrow wrote: On Monday, 7 November 2016 at 02:22:35 UTC, Steven Schveighoffer wrote: OP: it's not legal to destroy or even access GC allocated members in a destructor. The GC may have already destroyed that data. I would recommend printing the stack trace when you

Re: how to debug memory errors

2016-11-07 Thread Era Scarecrow via Digitalmars-d-learn
On Monday, 7 November 2016 at 02:22:35 UTC, Steven Schveighoffer wrote: OP: it's not legal to destroy or even access GC allocated members in a destructor. The GC may have already destroyed that data. I would recommend printing the stack trace when you get the exception, and figure out where

Re: how to debug memory errors

2016-11-07 Thread thedeemon via Digitalmars-d-learn
On Monday, 7 November 2016 at 02:22:35 UTC, Steven Schveighoffer wrote: OP: it's not legal to destroy or even access GC allocated members in a destructor. The GC may have already destroyed that data. Isn't destroy() fine there? It doesn't call destructors for already destroyed objects, so I

Re: how to debug memory errors

2016-11-07 Thread Lodovico Giaretta via Digitalmars-d-learn
On Sunday, 6 November 2016 at 21:46:52 UTC, Øivind wrote: Hi, My app occasionally gives me a *** Error in `./hauto-test': double free or corruption (fasttop): 0x7f504c002a60 *** but gives me the following on every termination

Re: how to debug memory errors

2016-11-07 Thread Steven Schveighoffer via Digitalmars-d-learn
On 11/6/16 5:15 PM, Lodovico Giaretta wrote: On Sunday, 6 November 2016 at 21:46:52 UTC, Øivind wrote: Hi, My app occasionally gives me a *** Error in `./hauto-test': double free or corruption (fasttop): 0x7f504c002a60 *** but gives me the following on every termination