|
From: Gurganus, B. L <gur...@ro...> - 2006-08-02 22:02:35
|
SSBhbSB0cnlpbmcgdG8gZGVidWcgc29tZSB1bmZyZWVkIG1lbW9yeSBpbiBhIHByb2plY3QgSSBh bSB3b3JraW5nIG9uLiBUaGV5IHN5c3RlbSB3b3JrcyB3aXRoIHNldmVyYWwgNi42IG1lZ2FwaXhl bCBpbWFnZXMgYXQgYSB0aW1lLiBJZiBJIHJ1biB0aGUgcHJvZ3JhbSBpbiB2YWxncmluZCBhbmQg ZG8gbWluaW1hbCB0aGluZ3MgaXQgdmVyeSBxdWlja2x5IHJ1bnMgb3V0IG9mIG1lbW9yeSBsZWFk aW5nIHRvIGludmFsaWQgKGZvciB0aGUgY3VycmVudCBwdXJwb3NlKSBtZW1vcnkgbGVha3MuIElm IEkgdXNlIG10cmFjZSwgSSBkZWZpbml0ZWx5IHNlZSBsYXJnZSBsZWFrcywgYnV0IEkgY2FuJ3Qg c2luY2UgdGhlIGxlYWtpbmcgbWFsbG9jcyBhcmUgaW4gbGlicmFyeSBjb2RlIGZyb20gdXNlcyBv ZiBmdW5jdGlvbnMgbGlrZSBjdkNyZWF0ZUltYWdlLCBJIGNhbid0IHRlbGwgd2hlcmUgdGhlIGNh bGxzIHRvIGZ1bmN0aW9ucyBsaWtlIHRoYXQgZG9uJ3QgaGF2ZSBhIGN2UmVsZWFzZUltYWdlLiBW YWxncmluZCB3aWxsIGdpdmUgYmFja3RyYWNlcyB0aGF0IGFyZSB1c2VmdWwsIGJ1dCBiZWNhdXNl IG9mIGl0cyBleHRyYSBtZW1vcnkgb3ZlcmhlYWQsIGV2ZW4gd2hlbiBJIGNyZWF0ZWQgYSBzd2Fw IGZpbGUgb2YgNEdCIChlbm91Z2ggdG8gY292ZXIgdGhlIG1heGltdW0gYWRkcmVzcyBzcGFjZSBv ZiBhIHByb2Nlc3MpLCB0aGUgbWVtb3J5IHJ1bnMgb3V0IGVhcmxpZXIgdGhhbiBJIGNhbiBnbyB0 byB0aGUgcHJvYmxlbWF0aWMgcG9ydGlvbiBvZiB0aGUgYXBwbGljYXRpb24gYW5kIHRoZW4gZXhp dCBjbGVhbmx5Lg0KDQpEbyB5b3UgaGF2ZSBhbnkgc3VnZ2VzdGlvbnMgaW4gZ2V0dGluZyB1c2Vm dWwgbG9jYXRpb25zIGluIHRoZSBjb2RlIGZvciB3aGljaCBJIGhhdmUgY29udHJvbCB3aXRob3V0 IHJ1bm5pbmcgb3V0IG9mIG1lbW9yeSBiZWZvcmUgYW55dGhpbmcgdXNlZnVsIGNhbiBiZSBkb25l Lg0KDQpCcmFudCBHdXJnYW51cw0KaHR0cDovL3d3dy5yb3NlLWh1bG1hbi5lZHUvfmd1cmdhbmJs DQoNCg== |
|
From: Nicholas N. <nj...@cs...> - 2006-08-02 22:38:06
|
On Wed, 2 Aug 2006, Gurganus, Brant L wrote: > I am trying to debug some unfreed memory in a project I am working on. > They system works with several 6.6 megapixel images at a time. If I run > the program in valgrind and do minimal things it very quickly runs out of > memory leading to invalid (for the current purpose) memory leaks. If I use > mtrace, I definitely see large leaks, but I can't since the leaking > mallocs are in library code from uses of functions like cvCreateImage, I > can't tell where the calls to functions like that don't have a > cvReleaseImage. Valgrind will give backtraces that are useful, but because > of its extra memory overhead, even when I created a swap file of 4GB > (enough to cover the maximum address space of a process), the memory runs > out earlier than I can go to the problematic portion of the application > and then exit cleanly. > > Do you have any suggestions in getting useful locations in the code for > which I have control without running out of memory before anything useful > can be done. You haven't given much info about how it fails, but if you're using a version prior to 3.2.0, switch to 3.2.0 where Memcheck uses substantially less memory (eg. 2--4x less). Nick |
|
From: Bryan M. <om...@br...> - 2006-08-02 23:02:58
|
Brant, if you are purely interested in memory leaks, please feel free to give my Omega tool a spin: http://www.brainmurders.eclipse.co.uk/omega.html If you use it, please post back to the list with how you got on. happy hunting, Bryan "Brain Murders" Meredith Gurganus, Brant L wrote: > I am trying to debug some unfreed memory in a project I am working on. > They system works with several 6.6 megapixel images at a time. If I run > the program in valgrind and do minimal things it very quickly runs out > of memory leading to invalid (for the current purpose) memory leaks. If > I use mtrace, I definitely see large leaks, but I can't since the > leaking mallocs are in library code from uses of functions like > cvCreateImage, I can't tell where the calls to functions like that don't > have a cvReleaseImage. Valgrind will give backtraces that are useful, > but because of its extra memory overhead, even when I created a swap > file of 4GB (enough to cover the maximum address space of a process), > the memory runs out earlier than I can go to the problematic portion of > the application and then exit cleanly. > > Do you have any suggestions in getting useful locations in the code for > which I have control without running out of memory before anything > useful can be done. > > Brant Gurganus > http://www.rose-hulman.edu/~gurganbl > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > ------------------------------------------------------------------------ > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Gurganus, B. L <gur...@ro...> - 2006-08-05 11:50:39
|
I tried the 3.2.0 version with the omega tool added. The 3.2.0 version =
allowed me to run the program and go through basic tasks without running =
out of memory almost immediately. I have discovered that no xForms =
object is being freed when it is done being used (using fl_free_object), =
and the X connection was not being shut down when the program exited =
(using fl_finish). When I added a call to fl_finish, that took care of =
about a third of the unreleased memory. It looks like I may have to =
modify the design of the software so that it uses lazy initialization =
and initializes when used so I can free it when not being used.
I also figured out how to work around some errors with strcpy have =
source and destinations that overlap in xForms. Apparently, it will do =
something like:
/* Set defaults. */
char scbt[64] =3D "thin"; /* scrollbar type */
/* Make a call to get resources. */
getResources(scbt, scbt);
/* Gets resources. */
void getResource(void *dst, void *default)
{
if !(getAppResource(dst))
{
strcpy(dst, default);
}
}
I can work around the problem in xForms by using an application-specific =
resource file which results in the destination and default for the =
resource not being the same.
I don't think there is an actual problem if the overlap in strcpy is =
exactly the same block since no way I can think of copying the data from =
one to the other would clobber the other, but this type of issue was =
happening so frequently that Valgrind would say more than 30000 errors =
detected, I'm not reporting anymore; go fix your program.
Anyhow, the quest continues in improving the robustness of the software =
I'm working on and making it use less memory. Thanks for the pointers to =
try the 3.2.0 version and the omega patch.
Brant Gurganus
http://www.rose-hulman.edu/~gurganbl
-----Original Message-----
From: Bryan Meredith [mailto:om...@br...]
Sent: Wed 08/02/06 7:02 PM
To: Gurganus, Brant L
Cc: val...@li...
Subject: Re: [Valgrind-users] debugging large memory usage
=20
Brant,
if you are purely interested in memory leaks, please feel free to give
my Omega tool a spin: http://www.brainmurders.eclipse.co.uk/omega.html
If you use it, please post back to the list with how you got on.
happy hunting,
Bryan "Brain Murders" Meredith
Gurganus, Brant L wrote:
> I am trying to debug some unfreed memory in a project I am working on.
> They system works with several 6.6 megapixel images at a time. If I =
run
> the program in valgrind and do minimal things it very quickly runs out
> of memory leading to invalid (for the current purpose) memory leaks. =
If
> I use mtrace, I definitely see large leaks, but I can't since the
> leaking mallocs are in library code from uses of functions like
> cvCreateImage, I can't tell where the calls to functions like that =
don't
> have a cvReleaseImage. Valgrind will give backtraces that are useful,
> but because of its extra memory overhead, even when I created a swap
> file of 4GB (enough to cover the maximum address space of a process),
> the memory runs out earlier than I can go to the problematic portion =
of
> the application and then exit cleanly.
>=20
> Do you have any suggestions in getting useful locations in the code =
for
> which I have control without running out of memory before anything
> useful can be done.
>=20
> Brant Gurganus
> http://www.rose-hulman.edu/~gurganbl
>=20
>=20
> =
------------------------------------------------------------------------
>=20
> =
-------------------------------------------------------------------------=
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =
share your
> opinions on IT & business topics through brief surveys -- and earn =
cash
> =
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
>=20
>=20
> =
------------------------------------------------------------------------
>=20
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Bryan M. <om...@br...> - 2006-08-05 13:02:34
|
Brant,
glad you have found your leaks.
Did you use Omega to find them?
If so, what information did Omega provide that helped you?
Also, are there any changes to the output that could have made it easier
to understand or simpler to use?
If you didn't use Omega, no problem - at least you have found the leaks now.
thanks in advance,
Bryan "Brain Murders" Meredith
Gurganus, Brant L wrote:
> I tried the 3.2.0 version with the omega tool added. The 3.2.0 version
> allowed me to run the program and go through basic tasks without running
> out of memory almost immediately. I have discovered that no xForms
> object is being freed when it is done being used (using fl_free_object),
> and the X connection was not being shut down when the program exited
> (using fl_finish). When I added a call to fl_finish, that took care of
> about a third of the unreleased memory. It looks like I may have to
> modify the design of the software so that it uses lazy initialization
> and initializes when used so I can free it when not being used.
> I also figured out how to work around some errors with strcpy have
> source and destinations that overlap in xForms. Apparently, it will do
> something like:
>
> /* Set defaults. */
> char scbt[64] = "thin"; /* scrollbar type */
>
> /* Make a call to get resources. */
> getResources(scbt, scbt);
>
> /* Gets resources. */
> void getResource(void *dst, void *default)
> {
> if !(getAppResource(dst))
> {
> strcpy(dst, default);
> }
> }
>
> I can work around the problem in xForms by using an application-specific
> resource file which results in the destination and default for the
> resource not being the same.
>
> I don't think there is an actual problem if the overlap in strcpy is
> exactly the same block since no way I can think of copying the data from
> one to the other would clobber the other, but this type of issue was
> happening so frequently that Valgrind would say more than 30000 errors
> detected, I'm not reporting anymore; go fix your program.
>
> Anyhow, the quest continues in improving the robustness of the software
> I'm working on and making it use less memory. Thanks for the pointers to
> try the 3.2.0 version and the omega patch.
>
> Brant Gurganus
> http://www.rose-hulman.edu/~gurganbl
>
>
>
> -----Original Message-----
> From: Bryan Meredith [mailto:om...@br...]
> Sent: Wed 08/02/06 7:02 PM
> To: Gurganus, Brant L
> Cc: val...@li...
> Subject: Re: [Valgrind-users] debugging large memory usage
>
> Brant,
>
> if you are purely interested in memory leaks, please feel free to give
> my Omega tool a spin: http://www.brainmurders.eclipse.co.uk/omega.html
>
> If you use it, please post back to the list with how you got on.
>
> happy hunting,
> Bryan "Brain Murders" Meredith
>
> Gurganus, Brant L wrote:
>> I am trying to debug some unfreed memory in a project I am working on.
>> They system works with several 6.6 megapixel images at a time. If I run
>> the program in valgrind and do minimal things it very quickly runs out
>> of memory leading to invalid (for the current purpose) memory leaks. If
>> I use mtrace, I definitely see large leaks, but I can't since the
>> leaking mallocs are in library code from uses of functions like
>> cvCreateImage, I can't tell where the calls to functions like that don't
>> have a cvReleaseImage. Valgrind will give backtraces that are useful,
>> but because of its extra memory overhead, even when I created a swap
>> file of 4GB (enough to cover the maximum address space of a process),
>> the memory runs out earlier than I can go to the problematic portion of
>> the application and then exit cleanly.
>>
>> Do you have any suggestions in getting useful locations in the code for
>> which I have control without running out of memory before anything
>> useful can be done.
>>
>> Brant Gurganus
>> http://www.rose-hulman.edu/~gurganbl
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
>> opinions on IT & business topics through brief surveys -- and earn cash
>>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|
|
From: Nicholas N. <nj...@cs...> - 2006-08-05 15:33:58
|
On Sat, 5 Aug 2006, Gurganus, Brant L wrote: > I don't think there is an actual problem if the overlap in strcpy is > exactly the same block since no way I can think of copying the data from > one to the other would clobber the other That's probably true, but it does seem strange that such copies are taking place, and maybe indicates that something is sub-optimal about the code... Nick |