What does "donut overflow" mean?

[Uncle 80]

Noticed this image in another thread, and a "donut overflow" bug is something I've never heard about (and can't seem to find any info about searching the forums or using google).

I'm wondering if anyone can tell me what this bug is and how/when it is triggered? I am of course asking because I'm making a map that has a lot of donuts. yum yum.

[Gez]

Here's some relevant code from PrBoom+:

#define DONUT_FLOORPIC_DEFAULT 0x16
int DonutOverrun(fixed_t *pfloorheight, short *pfloorpic)
{
    if (demo_compatibility && PROCESS(OVERFLOW_DONUT))
    {
        ShowOverflowWarning(OVERFLOW_DONUT, 0, "");
        if (EMULATE(OVERFLOW_DONUT))
        {
            if (pfloorheight && pfloorpic)
            {
                GetMemoryValue(0, pfloorheight, 4);
                GetMemoryValue(8, pfloorpic, 2);
                // bounds-check floorpic
                if ((*pfloorpic) <= 0 || (*pfloorpic) >= numflats)
                {
                    *pfloorpic = MIN(numflats - 1, DONUT_FLOORPIC_DEFAULT);
                }
                return true;
            }
        }
    }
    return false;
}

So apparently it's something to do with a donut not getting the correct floor picture.

There's also this in the history file:

Access violation emulation for the "S1 Floor Raise Donut (changes texture) (9)" action in demo compatibility mode. "-donut floorheight floorpic" - takes custom values, overriding the program's default values ("-donut 0xF1000000 7", for DOSBox behavior). Disabled by default.

So there's an access violation error that can happen in the vanilla code.

[scifista42]

If the lowest numbered linedef of the donut's "ascending pool" sector was single-sided, vanilla Doom would read and write data at an invalid memory address and result in undefined behavior. The option "Try to emulate it" tries to emulate this undefined behavior in PrBoom-plus when the bug already happens. But to make it possible for the bug to happen in the first place, you must set "Use exactly Doom's linedef trigger model" option to "Yes".

[Uncle 80]

Ah yes, perhaps that compatibility option is included for the rare occasion that a map depends on using line action 9 "wrong", i.e. getting the numeric model sector info from a 1-sided linedef (in which case the donut changes to the last flat in the direcotry and moves to "a strange height" according to Hank Leukarts old reliable faq)

edit: ninja'd by scifi42. Thank you both, seems I do not need to worry about this bug then, since all my donuts have a 2-s line as lowest numbered. Hugs and kisses!