I looked at the call before and after to see what they had set the buffer to, and they clearly set the buffer to point into what is code. The executable is only 5KB and it's tiny; they had plenty of space in the segment to use a different part of the segment without purposefully blasting their own code.
While it's common, it was still a terrible practice. If whatever was filling in that buffer changed, they could be blasting more code than they intended. (As indicated in what I wrote, I know it was common if they wanted to reuse the space. Device drivers do something similar when they are done with their init code.)
Here's the code from DOS 3.3. I am reasonably sure they didn't intend to overwrite code -- you're probably just seeing a weird artifact where the failure case is leaving a dangling random value that happens to point into valid code.
My guess is that DS isn't being maintained across the failing call to the IOCTL and ends up pointing to the wrong segment.
DOSOutFH DW ? ; fh of DOS destination
DumpMem:
MOV DX,OFFSET DG:BUF+512 ; get offset of bios start
MOV CX,pDOS ; beginning of next guy
SUB CX,DX ; difference is length
JZ DumpDos ; no bios to move
MOV BX,BIOSOutFH ; where to output
MOV AH,Write
INT 21h ; wham
retc ; error
CMP AX,CX ; Did it work?
JNZ WRERR ; No
DumpDos:
MOV DX,pDOS ; beginning of dos
MOV CX,pDOSEnd ; end of dos
SUB CX,DX ; difference is length
retz ; if zero no write
MOV BX,DOSOutFH ; where to output
MOV AH,Write
INT 21h ; wham
retc ; error
CMP AX,CX ; Did it work?
retz ; Yes, carry clear
I'm sure I can go for a few more years until the next patch ...
On a more serious note, the web server is the problem here. I've tried to run long periods of time before but eventually it would crash. I finally found a 10+ year old parsing bug that wasn't handling quoting correctly, and it was some sort of crypto coin mining JSON request that tripped the bug. So even what I thought was bullet proof years ago turned out to be broken by changes in the user traffic.
Sadly the project is mostly unrelated to my day job. I started mTCP at least 6 years before joining Google and at most of my time at Google is spent on much less fun things.
On the plus side, when I finally do get around to building a cluster of these and a load balancer I'll know what to do. ;)
There were several speeds of the V20, including the base version at 5Mhz. Using it as a drop-in replacement and keeping the system clock speed the same the NEC V20 would still give you a 15 to 20% performance bump because it used less clock cycles when executing many insgtructions.
(This machine has not been altered to speed the clock.)
The machine continues to receive the hug of death .. especially with our friendly Europeans waking up. Have faith, it's still running. (And it's been surviving like this for four hours now.)
I've turned down the logging level a little bit and turned off the beeper. On this machine, a 50ms beep on the motherboard buzzer is 50ms of delay. :)
I think it's impressive how your site's managed to stay online when many sites hosted on much more powerful hardware haven't been able to handle HN frontpage levels of traffic.
Thanks ... I think people are having time-outs so it's not anywhere near close to perfect, but the machine has been running at 100% for five hours or so now and it is not crashing, so I'm happy.
I very friendly opened the link, and it is still serving pages. The images are pretty slow to load, though. While reading the page, I thought it was just text, but then suddenly a banner appeared.
Great demo of what such a machine can do, and how much we take our 3GHz, 12 core machines for granted.
While it's common, it was still a terrible practice. If whatever was filling in that buffer changed, they could be blasting more code than they intended. (As indicated in what I wrote, I know it was common if they wanted to reuse the space. Device drivers do something similar when they are done with their init code.)