COIN-OR::LEMON - Graph Library

Opened 14 years ago

Closed 14 years ago

#332 closed defect (fixed)

Valgrind reports memory leak in arg_parser_demo

Reported by: Alpar Juttner Owned by: Alpar Juttner
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 Juttner 14 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 14 years ago by Alpar Juttner

Summary: Vargring reports memory leak in arg_parser_demoValgrind reports memory leak in arg_parser_demo

comment:2 Changed 14 years ago by Balazs Dezso

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 14 years ago by Alpar Juttner

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 Changed 14 years ago by Alpar Juttner

Status: newassigned

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 ; Changed 14 years ago by Alpar Juttner

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 14 years ago by Alpar Juttner

Attachment: c2ff0a365245.patch added

comment:6 in reply to:  5 Changed 14 years ago by Peter Kovacs

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 14 years ago by Alpar Juttner

Resolution: fixed
Status: assignedclosed

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.