Bug 7349 – assert(0) in class destructor - bad (or incorrect) error
Status
RESOLVED
Resolution
FIXED
Severity
minor
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2012-01-22T10:38:18Z
Last change time
2021-06-01T06:18:11Z
Assigned to
No Owner
Creator
Taco
Comments
Comment #0 by full.demon — 2012-01-22T10:38:18Z
class C
{
public:
this()
{
}
~this()
{
assert (0);
}
}
void main()
{
C c = new C;
}
Upon destruction, it throws:
core.exception.InvalidMemoryOperationError
Which is very vague / incorrectly describes the problem. The documentation also does not mention throwing exceptions is forbidden in destructors (or are they not?).
For debugging purposes I do like to assert some stuff in the destructor though...
Comment #1 by dbugz — 2014-05-20T08:50:01Z
Is this a bug or is it not allowed to assert in a destructor? I ran into this while running the druntime tests on Android/x86, was very annoying as the assert in core.sync.semaphore was swallowed up by the InvalidMemoryOperationError so I didn't know where it was actually coming from till I stuck printfs everywhere. If the assert shouldn't be allowed, druntime and possibly other D code needs to be cleaned up to get rid of any asserts in destructors.
Comment #2 by safety0ff.bugz — 2014-05-20T12:15:43Z
The current GC does not support allocation during destruction (quality of implementation issue.)
When the assert fails and tries to allocate it causes an invalid memory operation error.
Comment #3 by dbugz — 2014-05-20T17:15:49Z
(In reply to safety0ff.bugz from comment #2)
> The current GC does not support allocation during destruction (quality of
> implementation issue.)
> When the assert fails and tries to allocate it causes an invalid memory
> operation error.
Yeah, I know what's happening, which I wrote about in github, the question is how the people who build D plan on resolving it.
It doesn't help when druntime itself is asserting in its destructors, if this hasn't worked in a long time. Should we be taking all asserts out of destructors?
Comment #4 by bugzilla — 2014-11-13T10:59:40Z
The real problem is that assert(0) is attempting to allocate.
Comment #5 by dfj1esp02 — 2016-02-20T16:31:06Z
*** Issue 15705 has been marked as a duplicate of this issue. ***
Comment #8 by thomas.bockman — 2021-01-22T19:22:45Z
Given that assert(0) is intended to crash the program, wouldn't it also be reasonable to just allocate using stdc's malloc, or an OS-specific syscall, and not worry about explicitly freeing the memory? It's just going to get freed by the OS when the process terminates an instant later, anyway...
Comment #9 by pro.mathias.lang — 2021-06-01T06:18:11Z