A mystery with memory leaks and a magic number

Coming from a firmware background with code running for a long time, limited memory protection, potential for memory corruption due to hardware bugs, I have learned a lot of defensive programming techniques like fencing structs with magic numbers, checksums, duplicated fields. Even unused bits of struct bitfields are set to magic values, all to help catch source of rare corruptions while debugging and hardening the code.

Nothing like taking raw data off of the network, unchecked, and passing it to malloc().

I used to work with a programmer who never wrote bounds checking or error checking code. You could pass his programs anything and they'd do something. Something unexpected, to be sure... but they're do something, and never give a hint that things were going wrong.

In my opinion, GIGO is for idiots. If your program gets garbage in, it should complain loudly and refuse to do anything stupid.

And not entirely unexpected, a google search for

https://www.google.com/search?q=121348616

finds people asking about all sorts of errors like

[Zookeeper-User] Packet len 1213486160 is out of range

ERROR USER_LOGGER (MasterClient.java:getUserId) - Frame size (1213486160) larger than max length (16384000)!

I could read rachel's writing all day long.

Debugging is often intuition. Great story.

That's funny - I was analyzing a piece of malware a week or two ago that would have hit the exact same bug. I can't believe somebody would use a "protocol" like that in production code.

I suspect malloc('HTTPS') failed due to a certificate problem so it fell back on malloc('HTTP'). That in itself would be a security issue.