COIN-OR::LEMON - Graph Library

Opened 9 years ago

Closed 8 years ago

#332 closed defect (fixed)

Valgrind reports memory leak in arg_parser_demo

Reported by: alpar Owned by: alpar
Priority: major Milestone: LEMON 1.2 release
Component: core Version: hg main
Keywords: Cc:
Revision id: a2d5fd4c309a

Description

$ valgrind --leak-check=full ./arg_prser_demo
==4205== Memcheck, a memory error detector
==4205== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4205== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==4205== Command: ./arg_parser_demo
==4205== 
./arg_parser_demo: The following mandatory arguments are missing.
  -n int
     An integer input.
./arg_parser_demo: At least one of the following arguments is mandatory.
  -gra
     Choice A
  -grb
     Choice B
  -grc
     Choice C

Type './arg_parser_demo --help' to obtain a short summary on the usage.

==4205== 
==4205== HEAP SUMMARY:
==4205==     in use at exit: 1,373 bytes in 52 blocks
==4205==   total heap usage: 57 allocs, 5 frees, 1,441 bytes allocated
==4205== 
==4205== 154 bytes in 7 blocks are possibly lost in loss record 20 of 21
==4205==    at 0x4027400: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==4205==    by 0x40EDA64: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.12)
==4205==    by 0x80496D6: main (arg_parser_demo.cc:33)
==4205== 
==4205== 503 bytes in 26 blocks are possibly lost in loss record 21 of 21
==4205==    at 0x4027400: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==4205==    by 0x40EDA64: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.12)
==4205==    by 0x41AAACD: (below main) (in /lib/libc-2.10.1.so)
==4205== 
==4205== LEAK SUMMARY:
==4205==    definitely lost: 0 bytes in 0 blocks
==4205==    indirectly lost: 0 bytes in 0 blocks
==4205==      possibly lost: 657 bytes in 33 blocks
==4205==    still reachable: 716 bytes in 19 blocks
==4205==         suppressed: 0 bytes in 0 blocks
==4205== Reachable blocks (those to which a pointer was found) are not shown.
==4205== To see them, rerun with: --leak-check=full --show-reachable=yes
==4205== 
==4205== For counts of detected and suppressed errors, rerun with: -v
==4205== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 5 from 5)

Attachments (1)

c2ff0a365245.patch (4.6 KB) - added by alpar 8 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 9 years ago by alpar

  • Summary changed from Vargring reports memory leak in arg_parser_demo to Valgrind reports memory leak in arg_parser_demo

comment:2 follow-up: Changed 9 years ago by deba

If the mandatory parameters are not set, the program returns with exit(1) function. It does not clear the callstack, what is the reason of valgrind errors.

comment:3 in reply to: ↑ 2 Changed 9 years ago by alpar

Replying to deba:

If the mandatory parameters are not set, the program returns with exit(1) function. It does not clear the callstack, what is the reason of valgrind errors.

Is there any graceful way to stop the execution in C++? Or shoud we just live with it?

comment:4 follow-up: Changed 8 years ago by alpar

  • Status changed from new to assigned

A possible solution is to make ArgParser's way to exit configurable.

  • The current behavior (exiting on error and --help) remains the default.
  • The user can choose to throw exception instead. The it is possible the catch them in the main() and exit correctly.

comment:5 in reply to: ↑ 4 ; follow-ups: Changed 8 years ago by alpar

Replying to alpar:

A possible solution is to make ArgParser's way to exit configurable.

  • The current behavior (exiting on error and --help) remains the default.
  • The user can choose to throw exception instead. The it is possible the catch them in the main() and exit correctly.

[c2ff0a365245] is an implementation if this idea. I'm not very familiar with all the pitfalls of using exceptions in C++, so please review it carefully.

Changed 8 years ago by alpar

comment:6 in reply to: ↑ 5 Changed 8 years ago by kpeter

Replying to alpar:

[c2ff0a365245] is an implementation if this idea. I'm not very familiar with all the pitfalls of using exceptions in C++, so please review it carefully.

I like this solution, but I also don't know much about C++ exceptions.

comment:7 in reply to: ↑ 5 Changed 8 years ago by alpar

  • Resolution set to fixed
  • Status changed from assigned to closed

Replying to alpar:

[c2ff0a365245] is an implementation if this idea. I'm not very familiar with all the pitfalls of using exceptions in C++, so please review it carefully.

It has been merged to the main branch.

Note: See TracTickets for help on using tickets.