From: David K. <dknez@MIT.EDU> - 2009-09-29 21:42:46
|
I was using valgrind on an application code and in passing I checked the valgrind output for example 4 (see below). I'm not losing any sleep over 36 bytes, but I was just wondering if this (PETSc related?) leak has always been there or if perhaps it is due to some recent change in the library? (I'm using the SVN head with Petsc 3.0.0) Best, Dave ==3318== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 1 of 5 ==3318== at 0x4026FDE: malloc (vg_replace_malloc.c:207) ==3318== by 0x7BC3548: (within /lib/tls/i686/cmov/libc-2.9.so) ==3318== by 0x7BC3E25: __nss_database_lookup (in /lib/tls/i686/cmov/libc-2.9.so) ==3318== by 0x7C99F5B: ??? ==3318== by 0x7C9C00C: ??? ==3318== by 0x7B69A51: getpwuid_r (in /lib/tls/i686/cmov/libc-2.9.so) ==3318== by 0x7B693C6: getpwuid (in /lib/tls/i686/cmov/libc-2.9.so) ==3318== by 0x6ADF9E1: PetscGetUserName (fuser.c:68) ==3318== by 0x6AC8231: PetscErrorPrintfInitialize (errtrace.c:68) ==3318== by 0x6B1FAB2: PetscInitialize (pinit.c:521) ==3318== by 0x5DE11B7: SlepcInitialize (slepcinit.c:140) ==3318== by 0x48C07B1: libMesh::_init(int&, char**&, int) (libmesh.C:186) ==3318== ==3318== LEAK SUMMARY: ==3318== definitely lost: 36 bytes in 1 blocks. ==3318== indirectly lost: 120 bytes in 10 blocks. ==3318== possibly lost: 0 bytes in 0 blocks. ==3318== still reachable: 122,880 bytes in 6 blocks. ==3318== suppressed: 0 bytes in 0 blocks. |
From: John P. <pet...@cf...> - 2009-09-29 21:46:39
|
On Tue, Sep 29, 2009 at 4:42 PM, David Knezevic <dk...@mi...> wrote: > I was using valgrind on an application code and in passing I checked the > valgrind output for example 4 (see below). I'm not losing any sleep over > 36 bytes, but I was just wondering if this (PETSc related?) leak has > always been there or if perhaps it is due to some recent change in the > library? (I'm using the SVN head with Petsc 3.0.0) I've occasionally seen small leaks like this, where it looks like a system library is at fault. Not really sure what we can do about it though!? -- John |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2009-09-29 21:48:26
|
I've seen that too - to be sure we were good i compiled the library without petsc and verified that laspack was immune from the issue. if we report it to the petsc list i imagine it would get pretty low priority ;-) -Ben On 9/29/09 4:46 PM, "John Peterson" <pet...@cf...> wrote: > On Tue, Sep 29, 2009 at 4:42 PM, David Knezevic <dk...@mi...> wrote: >> I was using valgrind on an application code and in passing I checked the >> valgrind output for example 4 (see below). I'm not losing any sleep over >> 36 bytes, but I was just wondering if this (PETSc related?) leak has >> always been there or if perhaps it is due to some recent change in the >> library? (I'm using the SVN head with Petsc 3.0.0) > > I've occasionally seen small leaks like this, where it looks like a > system library is at fault. > > Not really sure what we can do about it though!? > > -- > John > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Roy S. <roy...@ic...> - 2009-09-29 21:52:22
|
On Tue, 29 Sep 2009, Kirk, Benjamin (JSC-EG311) wrote: > I've seen that too - to be sure we were good i compiled the library without > petsc and verified that laspack was immune from the issue. > > if we report it to the petsc list i imagine it would get pretty low priority > ;-) Low priority until we could confirm that it wasn't a bug in our PETSc interface, yeah. But they've got some excellent programmers there, and I suspect they'd take even a small memory leak seriously. When I sent them a feature request of "have you considered adding long double support?" years ago, it took them no time at all to go from "that's a good idea" to "you'll need to use a C BLAS, but it works now". --- Roy |
From: John P. <pet...@cf...> - 2009-09-29 21:54:54
|
I don't think this is PETSc's bug, they are just calling getpwuid()... -- John |
From: Roy S. <roy...@ic...> - 2009-09-29 22:02:31
|
On Tue, 29 Sep 2009, John Peterson wrote: > I don't think this is PETSc's bug, they are just calling getpwuid()... Do they call endpwent() when they're done with it? I think getpwuid implementations typically return pointers to allocated instead of static memory, for thread safety, but some implementations do use static buffers so you can't portably use free(). --- Roy |
From: Jed B. <je...@59...> - 2009-09-29 21:56:56
Attachments:
signature.asc
|
Kirk, Benjamin (JSC-EG311) wrote: > I've seen that too - to be sure we were good i compiled the library without > petsc and verified that laspack was immune from the issue. > > if we report it to the petsc list i imagine it would get pretty low priority > ;-) It's a libc issue, there's nothing you can do. The docs for getpwuid state | RETURN VALUE | The getpwnam() and getpwuid() functions return a pointer to a passwd structure, or NULL if the matching entry is not found or an error occurs. If an error occurs, | errno is set appropriately. If one wants to check errno after the call, it should be set to zero before the call. | | The return value may point to a static area, and may be overwritten by subsequent calls to getpwent(3), getpwnam(), or getpwuid(). (Do not pass the returned pointer | to free(3).) FWIW, I have glibc-2.10.1 and valgrind-3.5.0 on x86-64 and I do not see this warning. So either valgrind knows that it's spurious, or new libc implements it differently. Jed |
From: Jed B. <je...@59...> - 2009-09-29 22:25:43
Attachments:
signature.asc
|
Roy Stogner wrote: > On Tue, 29 Sep 2009, John Peterson wrote: > >> I don't think this is PETSc's bug, they are just calling getpwuid()... > > Do they call endpwent() when they're done with it? I'm not sure PETSc can call this, the user may expect it to be open. Consider pw = getpwent(); PetscInitialize(); /* pw should be valid */ PetscFinalize(); /* pw should still be valid */ endpwent(); I can't think of a reason why a user would *need* the semantics above, but it's certainly what one would expect. In the current implementation, even though pw will still be valid, its value may have changed (implementation dependent, and likely surprising). If you think PETSc should call endpwent(), feel free to raise the issue on the mailing list. Whoever wrote the pwd.h API should be tarred and feathered. Jed |
From: Roy S. <roy...@ic...> - 2009-09-29 22:38:03
|
On Wed, 30 Sep 2009, Jed Brown wrote: > Roy Stogner wrote: >> Do they call endpwent() when they're done with it? > > I'm not sure PETSc can call this, the user may expect it to be open. > Consider > > pw = getpwent(); > PetscInitialize(); > /* pw should be valid */ > PetscFinalize(); > /* pw should still be valid */ > endpwent(); Very good point; you're right. > I can't think of a reason why a user would *need* the semantics above, > but it's certainly what one would expect. In the current > implementation, even though pw will still be valid, its value may have > changed (implementation dependent, and likely surprising). If you think > PETSc should call endpwent(), feel free to raise the issue on the > mailing list. > > Whoever wrote the pwd.h API should be tarred and feathered. Hah! Yeah, even before "this isn't naturally thread-safe" became obvious, it should have been clear that they ought to be allocating dynamic memory for the strings in the struct passwd, and that there needed to be a good way to free that memory too. It looks like even the official reentrant API is a bit screwed up. You have to provide your own string buffer and length to getpwuid_r, and how long does that buffer need to be? Who knows?! Just test for ERANGE and keep feeding it more memory until the call succeeds! If I ever actually write the above strategy into robust code, I'll contribute it to PETSc. Until then, asking someone else to waste time working around an API that isn't their fault would just make me feel guilty. --- Roy |