@Bryan - yes, I inferred that from the nature of the crash.
I agree that (apart from a default limit, which should be a decent workaround), solving this is tricky. I haven't looked at the code yet, but it might be possible to guard against this by simply not allocating the entire buffer immediately, but rather a smaller interim buffer, and waiting to see if a valid message is forthcoming. This would work best if the rest of the unmarshalling code had thorough validity checks. This should avoid the attempt to allocate a meaninglessly large buffer in the case that the message can be rejected on other grounds. Of course, an attacker who's willing to craft a valid, extremely large Thrift message can still eat up server resources
I can look at this approach if you think it has merit.