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