Re: getpwuid memory leak?!?
Re: getpwuid memory leak?!?
- Subject: Re: getpwuid memory leak?!?
- From: Martin Bestmann <email@hidden>
- Date: Wed, 29 Nov 2006 17:43:48 +0100
On 04.08.2005, at 02:07, Marc Majka wrote:
There's a destructor function associated with the thread-specific
memory that is responsible for cleaning up when the thread exits.
See the pthread_exit(3) man page. Each of the Libinfo routines
attaches an appropriate destructor function, so the memory is not
supposed to leak when the thread exits. If you are seeing a
memory leak after a thread exits, let me know and I'll dig into it.
Hi Marc,
I need to come back to this old thread. We are now able to have a
reproducible case. Run this code with ObjectAlloc and you will see it
leaking every few seconds. We were able to reproduce this on two
machines (both PPC). This is really hurting us as we are running as a
daemon process that may not get restarted in months.
If you know about a workaround could you please share it with us. I
also filed a bug report (RADAR# 4854276).
Thanks,
Martin
-----------------------------------------------------
#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
#include <stdlib.h>
#include <pwd.h>
#define kThreadCount 1
#define kSleepTimeBetweenTests 0
typedef struct ThreadInfo {
int done;
int id;
pthread_t thread;
} ThreadInfo;
void* thread_entry(void* param)
{
ThreadInfo* threadInfo = (ThreadInfo*)param;
usleep(10000);
getpwuid(501);
threadInfo->done = 1;
return NULL;
}
static void thread_test()
{
unsigned i;
ThreadInfo threads[kThreadCount];
for ( i=0;i < kThreadCount; ++i ) {
threads[i].done = 0;
threads[i].id = i;
}
for ( i=0;i < kThreadCount; ++i ) {
int err = pthread_create(&threads[i].thread, NULL, &thread_entry,
&threads[i]);
if ( err ) {
fprintf(stderr, "couldn't create thread index = %u: %s\n", i,
strerror(err));
exit(1);
}
}
for ( ;; ) {
int done = 1;
for ( i=0;i < kThreadCount; ++i ) {
if ( threads[i].done == 0 )
done = 0;
if ( threads[i].done == 1 ) {
pthread_join(threads[i].thread, NULL);
threads[i].done = 2;
done = 0;
}
}
if ( done ) break;
}
}
int main (int argc, const char * argv[]) {
for (;;) {
thread_test();
if ( kSleepTimeBetweenTests ) sleep(kSleepTimeBetweenTests);
}
return 0;
}
-----------------------------------------------------
--
Marc Majka
On 3 Aug, 2005, at 15:13, Martin Bestmann wrote:
Does this also mean when the thread terminates that the memory
gets recycled.
I could verify that the memory in the same thread gets recycled if
I call getpwuid but I still have the memory allocated after my
thread terminates.
On 03.08.2005, at 23:40, Marc Majka wrote:
The Mac OS X implementations of a number of routines found in
libSystem, including getpwnam and getpwuid, have been modified to
be thread-safe. Rather than returning a pointer to a static data
structure, these routines allocate a structure for the returned
value that is stored in thread-specific memory. The memory is
recycled (by each thread) every time you make a call to one of
these routines. That allows you to use these APIs safely in
multi-threaded applications.
The specific routines in the Libinfo project (see Libinfo/
lookup.subproj/lu_*.c) that maintain thread-specific memory for
results are:
- alias_getbyname alias_getent alias_setent alias_endent
- bootp_getbyether bootp_getbyip
- bootparams_getbyname bootparams_getent bootparams_setent
bootparams_endent
- getfsbyname getfsspec getfsfile getfsent setfsent endfsent
- initgroups getgrnam getgrgid getgrent setgrent endgrent
- gethostbyaddr gethostbyname gethostbyname2 gethostent
sethostent endhostent
- getipnodebyname getipnodebyaddr
- innetgr getnetgrent setnetgrent endnetgrent
- getnetbyaddr getnetbyname getnetent setnetent endnetent
- prdb_getbyname prdb_get prdb_set prdb_end
- getprotobyname getprotobynumber getprotoent setprotoent
endprotoent
- getrpcbyname getrpcbynumber getrpcent setrpcent endrpcent
- getservbyport getservbyname getservent setservent endservent
- getpwnam getpwuid getpwent setpwent endpwent
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden