Resisting the urge to comment, but suffice to say I disagree entirely. The level of fail on display here is indicative of a total lack of understanding of the basic principles of working in C, with the CPython API, or as a company, any regard for quality control – even still 4 years after a trivially machine-detectable bug was introduced.

They don't even need Coverity, there are numerous cheaper and free static analysers that could have caught this before it left 10gen's offices.

Marketing a database server that crashes with such C-101 style bugs due to the shape of the data being stored is simply beyond.

I disagree that publicizing stupidity like this can do harm – the crash is clean enough that any trivial crash restart loop (e.g. just about any production web server) will catch it. In the meantime the company are much more motivated to provide a fix that I need, that I should never have needed in the first place.

For all the "responsible disclosure" idiocy on this thread, in most cases the crash is not remotely exploitable unless some API directly stores JSON objects provided by a user, and even then, amounts to little more than a slow request – a crash triggering a potentially expensive restart of the failed process. Useful for a DDoS perhaps, but not an immediate national security threat.

We happen to want this functionality since its one of the main "it's just JSON" selling points of Mongo to begin with, we want index visibility for the user data, and we think it's ridiculous that we should have to double-serialize the user data (and write our own indexing) in order to avoid obvious bugs.