@derickr / @bjori: Apparently the memory leaks were caused by stuffing the `document`, which is really the previous `zval *return_value`, into the exception as-is. They actually only surfaced in GridFS tests with `gridfs_rewrite_cursor_exception()`, which is called `storeBytes()` and `storeFile()`. My guess is the `MONGO_METHOD()` chaining complicates things.

Anyway, copying `return_value` here into a new zval avoided the leak, but I was confused that the `zval_ptr_dtor()` wasn't necessary to avoid the leak. Without that line, I'd expect the `error_doc` to be leaked. I took a peak inside [`zend_std_write_property()`](http://lxr.php.net/xref/PHP_5_5/Zend/zend_object_handlers.c#523) and it looks like the zval being assigned is copied in this case. Given that, it's not clear to me why the original `return_value` would have been an issue.

One more concern here regards `php_mongo_trigger_error_on_command_failure()`, which was originally used for `findAndModify()` and is also the function that I modeled this code after and call for a quick check on the GLE `ok` field. It doesn't do any zval copying before assigning a value to the exception property, and hasn't caused problems before. My concern is that if GLE does fail, we find ourselves (even with the old code before this PR) with a memory leak situation, since it's `zval *document` arugment will be our `return_value` here.