Non-unittest code crashes when built in unittest mode, but not when in debug/release. Is this a bug?
Nicolas F.
ddev at fratti.ch
Tue Feb 11 10:26:40 PST 2014
So I've been chasing after this issue for the better part of an
hour, and as I dug deeper, it just got weirder and weirder.
I have an Interface, let's call it PartyAnimal, and three
classes, one of which is exclusive to unittest.
class Equine is an abstract class that implements some of
PartyAnimal, but not the part where the bug occurs. class Pony
inherits from Equine, and has the code which triggers the crash.
Method whinny() is defined in Equine (without implementation),
implemented in Pony, but not defined or implemented in
PartyAnimal.
class Cow, which also inherits from PartyAnimal, is solely for
unittesting another class which has a list full of PartyAnimals,
and it only exists in unittest mode with version(unittest) {
/*definition goes here*/ }.
The unittests pass, everything is okay, and then the actual main
code calls the problematic method of Pony. It throws a
core.exception.InvalidMemoryOperationError error when creating a
new dynamic array of a size bigger than 2046 bytes, or allocating
memory (with GC.malloc) of a size bigger than 2048 bytes. But
only when compiled in unittest mode. It works like a charm in
debug and release mode. But it's code never touched by any
unittest.
Platform is Windows 7, compiler is DMD32 D Compiler v2.064. I
have tried to reproduce the problem in a test code, but was
unable to. This is why I'm not submitting it as bug report right
away: it's useless without test code.
However, maybe someone here has heard of the problem before, or
has any pointers to what could be going wrong, or ideas on how to
debug this any further.
More information about the Digitalmars-d
mailing list