1 Jan
2007
1 Jan
'07
7:16 a.m.
Found it! Testing is open again - hammer away at will!
(Hopefully this time I'm just going to sit back with a nice glow and
monitor it working perfectly.)
The postmortem:
Consistency checking is a good thing. The runtime of my compier has a
'heapcheck' function that walks the heap and verifies that everything is
in order. I have some code controlled by a #def that is doing this
checking (along with checking my own data structures) fairly often. It
impacts performance, but at least I can get closer the problem.)
There were almost no symptoms for this heap corruption - the machine was
running fine, sessions were still going, and DOS didn't behave badly
after I shut the server down. Nor could I see an obviously bad flow in
the traces. So I started diagnostics on the machine, thinking it was a
fluke.
While I was walking the dog this morning, it occurred to me what
happened. Simple buffer overun .. I allocated only 512 bytes for
output per session, but tried sending quite a bit more. Spc exposed my
crap coding with the 'sockets' command that showed nine sessions .. The
last time I tested with 9 simultaneous connections I didn't have the
consistency checking, so I was probably corrupting heap and not
realizing it.
Telnet users:
My understanding of telnet is that it is a protocol, not just raw
characters. So when you hit Ctrl-C under a typical Telnet client in
Unix, you are sending the equivalent of a 'process' interrupt.
I see lots of funny characters on my side, but they'll get consumed and
life goes on. I suspect that telnet is not so tolerant though, and is
expecting a proper response back from the telnet server. I don't have a
real telnet server here - it's not negotiating options or talking the
official protocol.
Short story .. don't bother with control chars. My code doesn't care,
and I think the normal telnet clients get tied up because my code isn't
responding right.
Anybody notice the BIOS date and machine ID? That's generated at
runtime, not a static string. :-)
Thanks again, and party on!
Mike