[CDRIVER-148] Memory leak using write_concern Created: 07/Jun/12  Updated: 08/May/17  Resolved: 29/Jun/12

Status: Closed
Project: C Driver
Component/s: None
Affects Version/s: 0.6
Fix Version/s: 0.7

Type: Bug Priority: Major - P3
Reporter: marcos grillo Assignee: Gary Murakami
Resolution: Done Votes: 0
Labels: leak, writeconcern
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

fedora Linux 2.6.35.13-92.fc14.i686.PAE #1 SMP i686 i686 i386 GNU/Linux


Attachments: Text File mongo-leak.c     Text File mongo-valgrind.txt     File mongo.c.patch    

 Description   

If you use the mongo_set_write_concern function it internally leaks the response bson of the mongo_check_last_error function. Attched there is some code that reproduces this and a valgrind trace with the leak.



 Comments   
Comment by marcos grillo [ 29/Jun/12 ]

Thank you for the fix

Comment by Gary Murakami [ 29/Jun/12 ]

Marcos, many thanks for your input. I hope that you like the fixes.

Comment by auto [ 29/Jun/12 ]

Author:

{u'date': u'2012-06-28T20:49:16-07:00', u'email': u'gary.murakami@10gen.com', u'name': u'Gary Murakami'}

Message: CDRIVER-148 Memory leak using write_concern
fix 3 driver leaks plus double free
leaks in mongo_check_last_error and mongo_run_command were serious
fix 29 leaks in tests
recommend documentation with highlighting and emphasis of memory management
Branch: master
https://github.com/mongodb/mongo-c-driver/commit/41f00af411b9f6b77daed03f9a6f54bef751474e

Comment by marcos grillo [ 28/Jun/12 ]

I've added a patch for this, please take a look at it

Comment by Gary Murakami [ 28/Jun/12 ]

As you can guess, this is fairly serious as mongo_check_last_error is used frequently.

Comment by Gary Murakami [ 28/Jun/12 ]

I also ran across this, thanks to valgrind - mongo_check_last_error calls mongo_find_one which allocates memory for the BSON "response", and bson_destroy is not called on "response", thus leaking memory.

We should run valgrind on EVERYTHING!

Generated at Wed Feb 07 21:08:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.