The Vertica Forum recently got a makeover! Let us know what you think by filling out this short, anonymous survey.

Vertica client 9.0.1 potential memory leak

I am connecting to vertica database (running version 9.0.1-6) with a client 9.0.1-4 and odbc version 3.52.7-7 on red-hat 7.6. Running valgrind on a simple example program found in the documentation (https://vertica.com/docs/9.0.x/HTML/index.htm#Authoring/ConnectingToVertica/ClientODBC/ConnectingToVertica.htm?TocPath=Connecting%20to%20Vertica|Client%20Libraries|Programming%20ODBC%20Client%20Applications|_____5) reports memory leaks (full output below). Am I missing something?

==25988== Memcheck, a memory error detector
==25988== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==25988== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info
==25988== Command: ./vertica
==25988==
Allocated an environment handle.
Set application version to ODBC 3.
Allocated Database handle.
Connecting to database.
Connected to database.
Disconnecting and freeing handles.
==25988==
==25988== HEAP SUMMARY:
==25988== in use at exit: 616 bytes in 3 blocks
==25988== total heap usage: 13,248 allocs, 13,245 frees, 3,802,001 bytes allocated
==25988==
==25988== 16 bytes in 1 blocks are definitely lost in loss record 1 of 3
==25988== at 0x4C29E83: malloc (vg_replace_malloc.c:299)
==25988== by 0x7B8B0C9: strdup (in /usr/lib64/libc-2.17.so)
==25988== by 0x500EB37: PQcreateConn (fe-connect.c:868)
==25988== by 0x4FE9298: Vertica::VPGConnection::Setup(std::string const&, std::string const&, std::string const&, std::string const&, std::string const&) (VPGConnection.cpp:77)
==25988== by 0x4FE1337: Vertica::VConnection::Connect(std::map<Simba::Support::simba_wstring, Simba::Support::Variant, Simba::Support::simba_wstring::CaseInsensitiveComparator, std::allocator<std::pair > > const&) (VConnection.cpp:440)
==25988== by 0x58C2E09: Simba::ODBC::ConnectionState2::SQLConnectW(Simba::ODBC::Connection*, wchar_t*, short, wchar_t*, short, wchar_t*, short) (ConnectionState2.cpp:285)
==25988== by 0x58B7BFE: Simba::ODBC::Connection::SQLConnectW(wchar_t*, short, wchar_t*, short, wchar_t*, short) (Connection.cpp:1273)
==25988== by 0x585FC80: Simba::ODBC::SQLConnectTask::DoSynchronously(Simba::ODBC::Connection&, Simba::ODBC::SQLConnectTask::TaskParameters const&) (SQLConnectTask.h:308)
==25988== by 0x58AA4EC: short DoTask<Simba::ODBC::SQLConnectTask >(char const*, void*, Simba::ODBC::SQLConnectTask::TaskParameters&) (CInterface.cpp:638)
==25988== by 0x5870A97: SQLConnect (CInterface.cpp:1293)
==25988== by 0x40083A: main (in ~/vertica)
==25988==
==25988== 32 bytes in 1 blocks are still reachable in loss record 2 of 3
==25988== at 0x4C2BF99: calloc (vg_replace_malloc.c:752)
==25988== by 0x7ECD54F: _dlerror_run (in /usr/lib64/libdl-2.17.so)
==25988== by 0x7ECCF80: [email protected]@GLIBC_2.2.5 (in /usr/lib64/libdl-2.17.so)
==25988== by 0x567C6AC: Simba::Support::StepUtilities::GetStepKey() (StepUtilities.cpp:33)
==25988== by 0x55E3B91: Simba::DSI::SharedSingletonManager::Initialize(bool) (SharedSingletonManager.cpp:95)
==25988== by 0x58EAE2C: Simba::ODBC::Driver::InitializeSingletons() (Driver.cpp:593)
==25988== by 0x58EC31A: Simba::ODBC::Driver::Initialize() (Driver.cpp:449)
==25988== by 0x5861BFF: GetDriver (Driver.h:250)
==25988== by 0x5861BFF: SQLAllocHandle (CInterface.cpp:681)
==25988== by 0x40072F: main (in ~/vertica)
==25988==
==25988== 568 bytes in 1 blocks are still reachable in loss record 3 of 3
==25988== at 0x4C29E83: malloc (vg_replace_malloc.c:299)
==25988== by 0x7B6DA3C: __fopen_internal (in /usr/lib64/libc-2.17.so)
==25988== by 0x4FE759D: parse_ini_filename(Vertica::IniData*, char const*) [clone .constprop.27] (VDriver.cpp:263)
==25988== by 0x4FE854F: SQLGetPrivateProfileString (VDriver.cpp:422)
==25988== by 0x58C72EF: void GetKeyValuePairsT(int (*)(char const*, char const*, char const*, char*, int, char const*), std::string const&, std::string const&, std::map<Simba::Support::simba_wstring, Simba::Support::Variant, Simba::Support::simba_wstring::CaseInsensitiveComparator, std::allocator<std::pair > >&) (ODBCIniReader.cpp:76)
==25988== by 0x58C6F49: Simba::ODBC::ODBCIniReader::GetKeyValuePairs(bool, Simba::Support::simba_wstring const&, std::map<Simba::Support::simba_wstring, Simba::Support::Variant, Simba::Support::simba_wstring::CaseInsensitiveComparator, std::allocator<std::pair > >&) (ODBCIniReader.cpp:293)
==25988== by 0x58CAFAC: Simba::ODBC::ConnectionSettings::ConnectionSettings(Simba::Support::simba_wstring const&, Simba::Support::simba_wstring const&, Simba::Support::simba_wstring const&, Simba::ODBC::Connection&) (ConnectionSettings.cpp:287)
==25988== by 0x58C2DAA: Simba::ODBC::ConnectionState2::SQLConnectW(Simba::ODBC::Connection*, wchar_t*, short, wchar_t*, short, wchar_t*, short) (ConnectionState2.cpp:269)
==25988== by 0x58B7BFE: Simba::ODBC::Connection::SQLConnectW(wchar_t*, short, wchar_t*, short, wchar_t*, short) (Connection.cpp:1273)
==25988== by 0x585FC80: Simba::ODBC::SQLConnectTask::DoSynchronously(Simba::ODBC::Connection&, Simba::ODBC::SQLConnectTask::TaskParameters const&) (SQLConnectTask.h:308)
==25988== by 0x58AA4EC: short DoTask<Simba::ODBC::SQLConnectTask >(char const*, void*, Simba::ODBC::SQLConnectTask::TaskParameters&) (CInterface.cpp:638)
==25988== by 0x5870A97: SQLConnect (CInterface.cpp:1293)
==25988==
==25988== LEAK SUMMARY:
==25988== definitely lost: 16 bytes in 1 blocks
==25988== indirectly lost: 0 bytes in 0 blocks
==25988== possibly lost: 0 bytes in 0 blocks
==25988== still reachable: 600 bytes in 2 blocks
==25988== suppressed: 0 bytes in 0 blocks
==25988==
==25988== For counts of detected and suppressed errors, rerun with: -v
==25988== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Answers

  • skeswaniskeswani Employee
    edited August 2019

    looks like the ini file and some key (that is a singleton).
    Can you put the desired code in a loop to establish a memory leak proportional to the action you are taking.
    Certain config and singleton objects will be loaded into memory and be kept there for the entire life of the program. (i.e. there is a baseline memory foot print that will always be in memory, and will include singletons and configs). That usually does not indicate a leak.

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Emoji
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file

Can't find what you're looking for? Search the Vertica Documentation, Knowledge Base, or Blog for more information.