www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Assert Memory Leak

reply AJG <AJG_member pathlink.com> writes:
Hi,

In asserterror.d, a string buffer is mallocated, and it is never freed. The
comments in the code say:

* We'll never free the malloc'd memory, but that doesn't matter,
* as we're aborting anyway.

In truth, assert doesn't "abort." Rather, it throws an exception, which can be
caught. In turn, this means means that program execution could perfectly well
continue despite a failed assertion. Therefore, in such a case, the unfreed
memory is leaked. Right?

Cheers,
--AJG.
Aug 17 2005
next sibling parent Vathix <chris dprogramming.com> writes:
On Wed, 17 Aug 2005 20:55:07 -0400, AJG <AJG_member pathlink.com> wrote:

 Hi,

 In asserterror.d, a string buffer is mallocated, and it is never freed.  
 The
 comments in the code say:

 * We'll never free the malloc'd memory, but that doesn't matter,
 * as we're aborting anyway.

 In truth, assert doesn't "abort." Rather, it throws an exception, which  
 can be
 caught. In turn, this means means that program execution could perfectly  
 well
 continue despite a failed assertion. Therefore, in such a case, the  
 unfreed
 memory is leaked. Right?
Yes. I was going to complain about this when it was added but forgot to.
Aug 17 2005
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"AJG" <AJG_member pathlink.com> wrote in message
news:de0m9b$np6$1 digitaldaemon.com...
 Hi,

 In asserterror.d, a string buffer is mallocated, and it is never freed.
The
 comments in the code say:

 * We'll never free the malloc'd memory, but that doesn't matter,
 * as we're aborting anyway.

 In truth, assert doesn't "abort." Rather, it throws an exception, which
can be
 caught. In turn, this means means that program execution could perfectly
well
 continue despite a failed assertion. Therefore, in such a case, the
unfreed
 memory is leaked. Right?
Assert is expected to abort the program, not attempt to continue. The only reason it can be caught is so that some necessary shut down code can be executed.
Aug 27 2005
parent Stewart Gordon <Stewart_member pathlink.com> writes:
In article <deqm8e$254o$3 digitaldaemon.com>, Walter says...

 "AJG" <AJG_member pathlink.com> wrote in message 
 news:de0m9b$np6$1 digitaldaemon.com...
<snip>
 In truth, assert doesn't "abort." Rather, it throws an exception, 
 which can be caught.  In turn, this means means that program 
 execution could perfectly well continue despite a failed 
 assertion.  Therefore, in such a case, the unfreed memory is 
 leaked.  Right?
Assert is expected to abort the program, not attempt to continue.
That's what I thought. However, I just realised another issue. When contract inheritance is finally implemented, then under the implementation logic I had suggested, there'll be a memory leak as a class's own in contract first generates an AssertError, which is then caught in order to try the inherited contract.
 The only reason it can be caught is so that some necessary shut 
 down code can be executed.
Isn't that what finally is for? Stewart.
Aug 28 2005
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
AJG wrote:
 Hi,
 
 In asserterror.d, a string buffer is mallocated, and it is never freed. The
 comments in the code say:
 
 * We'll never free the malloc'd memory, but that doesn't matter,
 * as we're aborting anyway.
 
 In truth, assert doesn't "abort." Rather, it throws an exception, which can be
 caught. In turn, this means means that program execution could perfectly well
 continue despite a failed assertion. Therefore, in such a case, the unfreed
 memory is leaked. Right?
Just thinking about it, the AssertError itself is created on the heap. So how is the exception message different? And what's wrong with using the destructor to free the memory? This would solve the problem in the odd cases where we're not aborting anyway, at virtually no cost to existing programs. Just add to AssertError ~this() { std.c.stdlib.free(msg.ptr); } Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Aug 31 2005