oranges
25a97a0f08
This is usually caused by logic in destroys that lead to the object being qdeleted again. This can cause nasty recursive loops, so an exception (with a stack trace) will prevent recursive stack crashes and also let devs chase the runtimes
17 lines
1.0 KiB
Plaintext
17 lines
1.0 KiB
Plaintext
//defines that give qdel hints. these can be given as a return in destory() or by calling
|
|
|
|
|
|
#define QDEL_HINT_QUEUE 0 //qdel should queue the object for deletion.
|
|
#define QDEL_HINT_LETMELIVE 1 //qdel should let the object live after calling destory.
|
|
#define QDEL_HINT_IWILLGC 2 //functionally the same as the above. qdel should assume the object will gc on its own, and not check it.
|
|
#define QDEL_HINT_HARDDEL 3 //qdel should assume this object won't gc, and queue a hard delete using a hard reference.
|
|
#define QDEL_HINT_HARDDEL_NOW 4 //qdel should assume this object won't gc, and hard del it post haste.
|
|
#define QDEL_HINT_PUTINPOOL 5 //qdel will put this object in the atom pool.
|
|
#define QDEL_HINT_FINDREFERENCE 6 //functionally identical to QDEL_HINT_QUEUE if TESTING is not enabled in _compiler_options.dm.
|
|
//if TESTING is enabled, qdel will call this object's find_references() verb.
|
|
//defines for the gc_destroyed var
|
|
|
|
#define GC_QUEUED_FOR_QUEUING -1
|
|
#define GC_QUEUED_FOR_HARD_DEL -2
|
|
#define GC_CURRENTLY_BEING_QDELETED -3
|