|
From: Ken S. <ken...@ya...> - 2005-09-11 21:35:45
|
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 |
|
From: Brian C. <cr...@fi...> - 2005-09-11 23:43:34
|
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
>
>
>
>
>
|
|
From: Brian C. <cr...@fi...> - 2005-09-11 23:50:05
|
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
>
>
>
|
|
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
|
|
From: Nicholas N. <nj...@cs...> - 2005-09-13 20:50:58
|
On Sun, 11 Sep 2005, Ken Stanley wrote: > 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. As Dirk says, if you have a test case and sample outputs from 2.0.0 and 2.2.0 (or 3.0.1) that will help a lot. It would be great if you could open a bug for this (see http://www.valgrind.org/support/bug_reports.html). Thanks. Nick |
|
From: Ken S. <ken...@ya...> - 2005-09-23 14:57:24
|
I submitted this as a bug, http://bugs.kde.org/show_bug.cgi?id=112731, but haven't heard anything on it. I recognize that this is a challenging bug to deal with, as I have been unable to reduce it to a self contained example. But, I was able to characterize it considerably and with a bit of help could characterize it further. Hopefully leading to a self contained example. Thanks, 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 |
|
From: Dirk M. <dm...@gm...> - 2005-09-12 11:04:55
|
On Sunday 11 September 2005 23:35, Ken Stanley wrote: > 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). do you have a selfcontained testcase that shows the problem you're experiencing? Dirk |