Opened 2 years ago

Last modified 9 months ago

#992 assigned defect

Memory Leaks

Reported by: gsemmler Owned by: drusu
Priority: minor Milestone: Future
Component: raslib Version: development
Keywords: Cc:
Complexity: Medium

Description

Using gcc-asan while debugging my own c++-code (which uses rasdamans c++ interface) i discovered a few memory leaks in raslib, rasodmg and rnprotocol.

Change History (7)

comment:1 Changed 22 months ago by dmisev

  • Resolution set to invalid
  • Status changed from new to closed

comment:2 Changed 21 months ago by gsemmler

  • Component changed from undecided to raslib
  • Resolution invalid deleted
  • Status changed from closed to reopened

This is not closed.

==32529==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 1708 byte(s) in 52 object(s) allocated from:
    #0 0x7ff715d3a76f in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x6276f)
    #1 0x11553f0 in r_Minterval::get_string_representation() const rasdaman/raslib/minterval.cc:851

Direct leak of 364 byte(s) in 52 object(s) allocated from:
    #0 0x7ff715d3a76f in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x6276f)
    #1 0x110478f in r_OQL_Query::operator<<(r_GMarray&) rasdaman/rasodmg/oqlquery.cc:368

Direct leak of 208 byte(s) in 13 object(s) allocated from:
    #0 0x7ff715d718b2 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x998b2)
    #1 0x11345f6 in RnpClientComm::RnpClientComm(char const*, int) ../rnprotocol/rnpclientcomm.cc:57

Direct leak of 13 byte(s) in 13 object(s) allocated from:
    #0 0x7ff715d709aa in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x989aa)
    #1 0x11335f4 in RnpClientComm::setStorageFormat(r_Data_Format, char const*) ../rnprotocol/rnpclientcomm.cc:1060

Direct leak of 13 byte(s) in 13 object(s) allocated from:
    #0 0x7ff715d709aa in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x989aa)
    #1 0x1133674 in RnpClientComm::setTransferFormat(r_Data_Format, char const*) ../rnprotocol/rnpclientcomm.cc:1082

Indirect leak of 1248 byte(s) in 13 object(s) allocated from:
    #0 0x7ff715d709aa in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x989aa)
    #1 0x1174f4c in r_Parse_Params::add(char const*, void*, r_Parse_Params::parse_param_type) rasdaman/raslib/parseparams.cc:83

SUMMARY: AddressSanitizer: 3554 byte(s) leaked in 156 allocation(s).

comment:3 Changed 20 months ago by dmisev

  • Milestone set to Future

How do we reproduce.. can you give more details?

comment:4 Changed 9 months ago by dmisev

  • Resolution set to wontfix
  • Status changed from reopened to closed

... due to lack of information on how to reproduce.

comment:5 Changed 9 months ago by gsemmler

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Steps to reproduce: Compile rasdaman with -fsanitize=address or -fsanitize=leak using a recent version of gcc or clang. See https://github.com/google/sanitizers/wiki/AddressSanitizer
Or simply lookup the source code location listed in comment 2. Most leaks are easy to spot. For example:

I've submitted a patch some time ago, that fixed some of those. It got rejected those days. I don't remember exactly why. If I remember correcty it was because I changed also some of the old unsafe str-functions to the safer strn ones.
http://rasdaman.org/patchmanager/rejected?patchop=Download+Selected-1687

comment:6 Changed 9 months ago by dmisev

Ok I thought you had a client program and identified the leaks with valgrind, so I was hoping you can attach the client code. Thanks for taking the time to provide more information.

comment:7 Changed 9 months ago by dmisev

  • Owner changed from dmisev to drusu
  • Status changed from reopened to assigned
Note: See TracTickets for help on using tickets.