It is possible for the Q3VM stack and data segment to overlap, which is very bad. Below is the write up that I made a long time ago and mentioned once on the mailing list but never filed a bug for:
Consulting vm.c:VM_LoadQVM()
If you see the definition of the "dataMask", you'll see it is the next highest power of two that is greater than the sum of data, lit, and bss segments. So, if the their sum was say, 400 bytes, then the next highest power of two would be 512, and the mask would be 0x1FF (decimal 511). Let's continue with this example. The stack grows down, and is implicity at the end of the image. This means that the
[data+lit+bss = 400][Extra space 112 bytes]
^------------------------------------------^ Whole allocation is 512 bytes.
Let's suppose the stack size was 256 bytes. This means:
Stack size of 256 bytes
v---------------------------v
[data+lit+bss = 400][Extra space 112 bytes]
^------------------^
[ !!! ]
The area marked as [ !!! ] is the overlap of the two.
This can easily be fixed by changing the calculation of "dataLength" in vm.c to:
dataLength = header.h->dataLength + header.h->litLength + header.h->bssLength + STACK_SIZE;
This has not yet been a problem, but the closer the sum (header.h->dataLength + header.h->litLength + header.h->bssLength) is to a power of two, the more likely the error is to occur.
This is in q3asm.c ...
// reserve the stack in bss
DefineSymbol( "_stackStart", segment[BSSSEG].imageUsed );
segment[BSSSEG].imageUsed += stackSize;
DefineSymbol( "_stackEnd", segment[BSSSEG].imageUsed );
...stackSize is 0x10000.
So, yeah, we allocate space for the stack at the end of the BSS in the assembler.
Note that the QVM interpreter defines STACK_SIZE to be 0x20000, though, so it's possible we _could_ overflow it, I guess.
Patrick's patch probably fixes that possibility (although _stackEnd is probably wrong at runtime), at a cost of some kilobytes of memory, but it's not clear to me if it's safe to either lower STACK_SIZE in the virtual machine or raise stackSize in the assembler to otherwise account for the difference, so I don't really know which approach is best.
--ryan.
It is possible for the Q3VM stack and data segment to overlap, which is very bad. Below is the write up that I made a long time ago and mentioned once on the mailing list but never filed a bug for: Consulting vm.c:VM_LoadQVM() If you see the definition of the "dataMask", you'll see it is the next highest power of two that is greater than the sum of data, lit, and bss segments. So, if the their sum was say, 400 bytes, then the next highest power of two would be 512, and the mask would be 0x1FF (decimal 511). Let's continue with this example. The stack grows down, and is implicity at the end of the image. This means that the [data+lit+bss = 400][Extra space 112 bytes] ^------------------------------------------^ Whole allocation is 512 bytes. Let's suppose the stack size was 256 bytes. This means: Stack size of 256 bytes v---------------------------v [data+lit+bss = 400][Extra space 112 bytes] ^------------------^ [ !!! ] The area marked as [ !!! ] is the overlap of the two. This can easily be fixed by changing the calculation of "dataLength" in vm.c to: dataLength = header.h->dataLength + header.h->litLength + header.h->bssLength + STACK_SIZE; This has not yet been a problem, but the closer the sum (header.h->dataLength + header.h->litLength + header.h->bssLength) is to a power of two, the more likely the error is to occur.