#defines can crash Dream Maker in some cases.

ID:2031253
 
Feb 6 2016, 4:45 am
BYOND Version:510.1322
Operating System:Windows 10 Pro 64-bit
Web Browser:Chrome 48.0.2564.97
Applies to:Dream Maker
Status: Open
Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Redefining the built-in directions using preprocessor macros can crash Dream Maker if the direction is included in the macro definition.

This causes error: macro recursion level too deep:
#define NORTH NORTH

Is this normal? In stddef.dm the directions seem to be defined as const vars, not #defines.

If you add parentheses, Dream Maker will stop working altogether:
#define NORTH (NORTH)

Either way, if it causes a crash, then it's definitely a bug.
Feb 9 2016, 11:53 am
I think this post literally made me understand the term "Sanity Check".
Feb 9 2016, 3:07 pm
Sanity checks are what debugging is all about.

Anyway, this is a very ancient bug, going back to at least version 354, although it doesn't occur in that version until you actually try to use the macro.

Here is another case, to give you a better idea of what is going on:

This compiles on its own:
#define NORTH (SOUTH + 1)

This also compiles:
#define SOUTH (NORTH + 1)

Try to compile both, and Dream Maker stops working:
#define NORTH (SOUTH + 1)
#define SOUTH (NORTH + 1)

This results in error: macro recursion level too deep, which shouldn't happen either:
#define NORTH SOUTH + 1
#define SOUTH NORTH + 1

I don't know if any other vars or constants act like the directions.

Also, could this bug be related? They are both ancient, and they seem to have some similarities.
Feb 9 2016, 10:51 pm
510.1322 on Linux does not stop working, possibly only happens on the graphical Windows version.
#define NORTH NORTH // error: macro recursion level too deep


#define NORTH (NORTH) // error: infinitely recursive macro suspected


#define NORTH (SOUTH + 1) // error: infinitely recursive macro suspected
#define SOUTH (NORTH + 1)


#define NORTH SOUTH + 1 // error: macro recursion level too deep
#define SOUTH NORTH + 1
Feb 10 2016, 9:27 am
In response to GinjaNinja32
If that's true, then it must be something specific to the Windows version in general, and not just the GUI one. I just tested this with dm.exe on Windows and it also stops working.
Feb 10 2016, 9:58 am
Just in case it helps, here are some error logs:

Dream Maker:
Faulting application name: dreammaker.exe, version: 5.0.510.1322, time stamp: 0x56afd4bd
Faulting module name: byondcore.dll, version: 5.0.510.1322, time stamp: 0x56afd331
Exception code: 0xc00000fd
Fault offset: 0x00081bc4
Faulting process id: 0x7b0
Faulting application start time: 0x01d163828f98ffde
Faulting application path: C:\Program Files (x86)\BYOND\bin\dreammaker.exe
Faulting module path: C:\Program Files (x86)\BYOND\bin\byondcore.dll
Report Id: 6248a157-6246-4c3b-a7a9-84d234045eb9
Faulting package full name: 
Faulting package-relative application ID:

dm.exe:
Faulting application name: dm.exe, version: 5.0.510.1322, time stamp: 0x56afd332
Faulting module name: byondcore.dll, version: 5.0.510.1322, time stamp: 0x56afd331
Exception code: 0xc00000fd
Fault offset: 0x00080ea3
Faulting process id: 0x3850
Faulting application start time: 0x01d1641e5eb60b00
Faulting application path: C:\Program Files (x86)\BYOND\bin\dm.exe
Faulting module path: C:\Program Files (x86)\BYOND\bin\byondcore.dll
Report Id: 22786a93-3094-4ea0-bce2-748a6dfa8831
Faulting package full name: 
Faulting package-relative application ID:
Feb 10 2016, 10:06 am
Makes sense. Windows has a shallower stack than Linux.
Jun 7 2016, 3:15 am
So I had a nice little stack overflow crash in DM, I was gonna put up a bug report, when i remembered that I made a macro that referenced another macro with a similar name, and lo and behold, I messed up the name and had it referencing itself, not the similar macro.

Anywho, I figured detecting this might be worth looking at detecting, even if it's just a stack counter (ideally a full on array tracking solution might be worth looking at so you can print out all macros in the identified loop to help programmers identify really complex dereferencing loops.)

Put it on the backburner as something to look at once 511's initial release is out.

edit: actually, on second thought, this could happen with all defines, not just macros, couldn't it.
Jun 7 2016, 8:29 am
In response to MrStonedOne
Jun 7 2016, 9:26 am
In response to MrStonedOne
Good catch, GN. I'll combine the threads.