[CDRIVER-1029] mongoc_collection_find_and_modify will cause memory leakage if reply is created by bson_new() Created: 03/Dec/15 Updated: 23/Feb/16 Resolved: 23/Feb/16 |
|
| Status: | Closed |
| Project: | C Driver |
| Component/s: | docs, libmongoc |
| Affects Version/s: | 1.2.0, 1.2.1 |
| Fix Version/s: | 1.4.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jeson Chen | Assignee: | A. Jesse Jiryu Davis |
| Resolution: | Done | Votes: | 0 |
| Labels: | Bug | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
windows 7 sp1 |
||
| Description |
|
in function: mongoc_collection_find_and_modify code:
with
then will cause memory leakage:
reason: eg:
2.
both code piece of code will cause memory leakage. |
| Comments |
| Comment by Githook User [ 23/Feb/16 ] |
|
Author: {u'username': u'ajdavis', u'name': u'A. Jesse Jiryu Davis', u'email': u'jesse@mongodb.com'}Message: |
| Comment by A. Jesse Jiryu Davis [ 07/Dec/15 ] |
|
Updating the documentation isn't merely easier--I don't believe there's any other solution possible. mongoc_collection_find_and_modify expects an uninitialized bson_t *reply. If you pass it an initialized bson_t, like the one returned by bson_new(), it's impossible for mongoc_collection_find_and_modify to reliably detect that "reply" is already initialized. I'm going to confer with my colleagues about this before settling on a course of action, though. In any case there's nothing for you to do, thanks for reporting this. |
| Comment by Jeson Chen [ 07/Dec/15 ] |
|
Right, it's much easier to update the document, like bson_copy_to. So is there anything I can do? Open another issue or just leave it alone and someone will deal with it? |
| Comment by A. Jesse Jiryu Davis [ 03/Dec/15 ] |
|
Thanks for the report, I understand the problem. The solution may simply be to update the documentation to emphasize that "reply" must be uninitialized before calling mongoc_collection_find_and_modify, and it must be bson_destroyed after the call. This is a similar documentation issue to |