Opened 9 years ago

Closed 6 years ago

#644 closed defect (invalid)

[kean] Memory leaks in asiolink

Reported by: vorner Owned by: kean
Priority: medium Milestone: Sprint-20131015
Component: Unclassified Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 0.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no


#614 output hints that there's lost memory in around asiolink (or, at last in asiolink tests). As I look into the output, it seems there are 3 possible places where the memory may leak:

  • DNSService::DNSService (or, this one might be actually the test creating the DNSService object and not returning it)
  • IOEndPoint::create
  • RecursiveQuery::resolver

These should be examined (if they are actually caused by our code or the tests) and fixed.


Attachments (1)

asiolink.valgrind (12.8 KB) - added by vorner 9 years ago.
Valgrind output

Download all attachments as: .zip

Change History (9)

Changed 9 years ago by vorner

Valgrind output

comment:1 Changed 9 years ago by stephen

  • Milestone A-Team-Task-Backlog deleted

Milestone A-Team-Task-Backlog deleted

comment:2 Changed 8 years ago by shane

  • Defect Severity set to N/A
  • Milestone set to New Tasks
  • Sub-Project set to DNS

We probably need to run this test again. We have some information on the ProfilingValgrind page which might help.

comment:3 Changed 8 years ago by shane

  • Milestone New Tasks deleted

comment:4 Changed 6 years ago by muks

  • Milestone set to Sprint-20130903
  • Summary changed from Memory leaks in asiolink to [kean] Memory leaks in asiolink

comment:5 Changed 6 years ago by kean

  • Owner set to kean
  • Status changed from new to accepted

comment:6 Changed 6 years ago by kean

  • Owner changed from kean to UnAssigned
  • Status changed from accepted to reviewing

This bug, which was filed over three years ago, seems to be no longer applicable:

$ valgrind --leak-check=full --show-reachable=yes $PWD/run_unittests > foo
==20857== Memcheck, a memory error detector
==20857== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==20857== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==20857== Command: /home/kean/isc/X/src/lib/asiolink/tests/.libs/run_unittests
==20857== HEAP SUMMARY:
==20857==     in use at exit: 4 bytes in 1 blocks
==20857==   total heap usage: 2,820 allocs, 2,819 frees, 366,365 bytes allocated
==20857== 4 bytes in 1 blocks are still reachable in loss record 1 of 1
==20857==    at 0x4A068F3: operator new(unsigned long) (in /usr/lib64/valgrind/
==20857==    by 0x52C7BDE: ??? (in /usr/lib64/
==20857==    by 0x52B096F: ??? (in /usr/lib64/
==20857==    by 0x3364C0F4F2: _dl_init (in /usr/lib64/
==20857==    by 0x3364C01459: ??? (in /usr/lib64/
==20857== LEAK SUMMARY:
==20857==    definitely lost: 0 bytes in 0 blocks
==20857==    indirectly lost: 0 bytes in 0 blocks
==20857==      possibly lost: 0 bytes in 0 blocks
==20857==    still reachable: 4 bytes in 1 blocks
==20857==         suppressed: 0 bytes in 0 blocks
==20857== For counts of detected and suppressed errors, rerun with: -v
==20857== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

comment:7 Changed 6 years ago by muks

  • Owner changed from UnAssigned to kean

I've checked it locally and agree. The only leaks seem to be in log4cplus (maybe due to the logger object).

You can go ahead and resolve this ticket.

comment:8 Changed 6 years ago by kean

  • Resolution set to invalid
  • Status changed from reviewing to closed
Note: See TracTickets for help on using tickets.