|
From: Ken S. <ken...@ya...> - 2005-09-12 00:17:38
|
Brian,
I appreciate the quick response. I should have mentioned that I do indeed
include --show-reachable=yes in the valgrind command line. But, the symptoms
are still as I stated earlier: valgrind version 2.0.0 catches the error,
version 2.2.0 does not.
Ken
--- Brian Crowder <cr...@fi...> wrote:
>
> Actually, thinking on this some more, I think my original answer is
> incorrect or imprecise:
>
> char *ptr;
>
> int
> main()
> {
> ptr = new char[10];
> return;
> }
>
> Is a better example of an allocation which will not be reported by
> valgrind as a direct or indirect leak. Even after main() returns, ptr
> is still valid, reachable memory (I believe valgrind does its reporting
> after main). This probably explains why your factory-generated objects
> aren't being reported. You likely have a global automagic variable
> that's hanging onto them. My original suggestion still holds, though.
> Try --show-reachable.
>
> -- Brian
>
> Brian Crowder wrote:
>
> >
> > int
> > main()
> > {
> > char *ptr = new char[10]
> > return;
> > }
> >
> > Isn't necessarily a leak for valgrind. Your memory is still
> > referencABLE, just not destroyed explicitly. If you want to see
> > -everything- that hasn't been destroyed, run your program with
> > --show-reachable=yes
> >
> > Ken Stanley wrote:
> >
> >> In my application, Amesos,
> >> http://software.sandia.gov/trilinos/packages/amesos/index.html,
> >> many memory leaks are not found by valgrind 2.2 and 3.01. Pointers
> >> (or other
> >> structures) defined in one of the Amesos classes, and allocated but not
> >> deallocated are not identified as being lost or even reachable.
> >> I have even added a bogus pointer, allocated space for it using new
> >> int[10],
> >> never deallocating it. This is not caught by valgrind 3.01. (I did
> >> not check
> >> 2.2 on this particular case).
> >> These memory leaks are not caught when the Amesos classes are created
> >> through a
> >> factory interface, but they are caught when the Amesos classes are
> >> created
> >> directly (not through the factory interface).
> >>
> >> Ken
> >>
> >> Ken Stanley
> >> 440 774 4322 7AM-9PM Eastern Time
> >>
> >>
> >> -------------------------------------------------------
> >> SF.Net email is Sponsored by the Better Software Conference & EXPO
> >> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> >> Practices
> >> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> >> & QA
> >> Security * Process Improvement & Measurement *
> >> http://www.sqe.com/bsce5sf
> >> _______________________________________________
> >> Valgrind-users mailing list
> >> Val...@li...
> >> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> > & QA
> > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
> >
> >
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
Ken Stanley
440 774 4322 7AM-9PM Eastern Time
|