[SERVER-4211] Why is Valgrind complaining at every single connection? Created: 04/Nov/11  Updated: 29/May/12  Resolved: 17/Nov/11

Status: Closed
Project: Core Server
Component/s: Internal Client
Affects Version/s: 1.8.3
Fix Version/s: None

Type: Question Priority: Major - P3
Reporter: Traktor Toni Assignee: Brandon Diamond
Resolution: Incomplete Votes: 0
Labels: memory-leak
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

DBClientConnection c;
c.connect("localhost");

Valgrind output:

37 bytes in 1 blocks are possibly lost in loss record 6 of 27
in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) in /usr/lib64/libstdc++.so.6.0.14
1: operator new(unsigned long) in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so
2: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) in /usr/lib64/libstdc++.so.6.0.14
3: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) in /usr/lib64/libstdc++.so.6.0.14
4: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) in /usr/lib64/libstdc++.so.6.0.14
5: mongo::Command::Command(char const*, bool, char const*) in /usr/src/packages/BUILD/mongodb-src-r1.8.3/db/commands.cpp:98
6: global constructors keyed to connpool.cpp in /usr/src/packages/BUILD/mongodb-src-r1.8.3/client/connpool.cpp:262
7: mongocpp
8: mongocpp
9: /usr/lib64/libstdc++.so.6.0.14
10: __libc_csu_init in /usr/src/packages/BUILD/glibc-2.11.3/csu/elf-init.c:120
11: (below main) in /lib64/libc-2.11.3.so

37 bytes in 1 blocks are possibly lost in loss record 7 of 27
in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) in /usr/lib64/libstdc++.so.6.0.14
1: operator new(unsigned long) in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so
2: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) in /usr/lib64/libstdc++.so.6.0.14
3: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) in /usr/lib64/libstdc++.so.6.0.14
4: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) in /usr/lib64/libstdc++.so.6.0.14
5: mongo::Command::Command(char const*, bool, char const*) in /usr/src/packages/BUILD/mongodb-src-r1.8.3/db/commands.cpp:117
6: global constructors keyed to connpool.cpp in /usr/src/packages/BUILD/mongodb-src-r1.8.3/client/connpool.cpp:262
7: mongocpp
8: mongocpp
9: /usr/lib64/libstdc++.so.6.0.14
10: __libc_csu_init in /usr/src/packages/BUILD/glibc-2.11.3/csu/elf-init.c:120
11: (below main) in /lib64/libc-2.11.3.so

38 bytes in 1 blocks are possibly lost in loss record 8 of 27
in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) in /usr/lib64/libstdc++.so.6.0.14
1: operator new(unsigned long) in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so
2: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) in /usr/lib64/libstdc++.so.6.0.14
3: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) in /usr/lib64/libstdc++.so.6.0.14
4: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) in /usr/lib64/libstdc++.so.6.0.14
5: mongo::Command::Command(char const*, bool, char const*) in /usr/src/packages/BUILD/mongodb-src-r1.8.3/db/commands.cpp:98
6: global constructors keyed to connpool.cpp in /usr/src/packages/BUILD/mongodb-src-r1.8.3/client/connpool.cpp:277
7: mongocpp
8: mongocpp
9: /usr/lib64/libstdc++.so.6.0.14
10: __libc_csu_init in /usr/src/packages/BUILD/glibc-2.11.3/csu/elf-init.c:120
11: (below main) in /lib64/libc-2.11.3.so



 Comments   
Comment by Brandon Diamond [ 17/Nov/11 ]

This is related to the map of command names to commands. The allocation is interleaved with the server's initial fork which makes this somewhat tricky to fix. Importantly, this leak will not grow over time – though a small, constant number of blocks will not be cleanly deallocated. I am creating a more specific ticket to address the cause of this leak.

Generated at Thu Feb 08 03:05:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.