digitalmars.D.bugs - Assert Memory Leak
- AJG <AJG_member pathlink.com> Aug 17 2005
- Vathix <chris dprogramming.com> Aug 17 2005
- "Walter" <newshound digitalmars.com> Aug 27 2005
- Stewart Gordon <Stewart_member pathlink.com> Aug 28 2005
- Stewart Gordon <smjg_1998 yahoo.com> Aug 31 2005
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
Vathix <chris dprogramming.com> 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
"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.
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
caught. In turn, this means means that program execution could perfectly
continue despite a failed assertion. Therefore, in such a case, the
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
In article <deqm8e$254o$3 digitaldaemon.com>, Walter says..."AJG" <AJG_member pathlink.com> wrote in message news:de0m9b$np6$1 digitaldaemon.com...
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
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