[CDRIVER-2194] Memory leaks in mongoc-cluster.c Created: 20/Jun/17  Updated: 22/Jun/17  Resolved: 22/Jun/17

Status: Closed
Project: C Driver
Component/s: libmongoc
Affects Version/s: 1.6.3
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Rafael de Lucena Valle Assignee: A. Jesse Jiryu Davis
Resolution: Cannot Reproduce Votes: 0
Labels: Bug, driver
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

libmongoc 1.6.3


Attachments: Text File memleax3.log    

 Description   

Using a custom version of collectd (based on 5.4.3) with libmongoc-1.6.3, I found some memory leaks and some of them are in the libmongoc, specially on:

From mongoc-cluster.c

1473    if (stream) {
1474       sd = mongoc_topology_server_by_id (topology, server_id, error);
1475
1476       if (!sd) {
1477          return NULL;
1478       }
1479    } else {



 Comments   
Comment by A. Jesse Jiryu Davis [ 22/Jun/17 ]

I've manually inspected the first few code paths, and it seems like memleax is giving you false positives. It thinks all the server_description_t pointers passed to mongoc_server_stream_new() are leaked, when in fact they are freed in mongoc_server_stream_cleanup(). It also thinks the bson_t "cmd" that grows to fit demand in _mongoc_write_command() is leaked, but that function always calls bson_destroy (&cmd) before exiting.

Comment by Rafael de Lucena Valle [ 21/Jun/17 ]

Looking with more time at the code, I think this can be a false positive because of behavior of memleax tool.

Usage: memleax [options] target-pid
Options:
  -e <expire>
      set memory free expire time, default is 10 seconds.
      you should always set this according to your scenarios.
  -d <debug-info-file>
      set debug-info file.
  -m <memory-block-max>
      stop monitoring if number of expired memory block
      at a same CallStack exceeds this. default is 1000.
  -c <call-stack-max>
      stop monitoring if number of CallStacks with memory
      leak exceeds this. default is 1000.
  -l <backtrace-limit>
      set backtrace depth limit. less backtrace, better
      performance. max is 50, and default is max.
  -h  print help.
  -v  print version.

If it is, sorry about the misleading issue.

Comment by A. Jesse Jiryu Davis [ 20/Jun/17 ]

Interesting, thanks. I wonder why we haven't caught the same errors in Coverity or valgrind? We'll take a look.

Comment by Rafael de Lucena Valle [ 20/Jun/17 ]

Sorry about the title, can I edit this?

Best regards

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