This is the mail archive of the pthreads-win32@sources.redhat.com mailing list for the pthreas-win32 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Memory leak problem in MSVS6.0 C RTL


In the 2000-12-29 snapshot I have separated the DLL_*_ATTACH/DETACH
code out into non-portable routines (pthread_thread_detach_np etc).
dllMain now calls these routines. I have also modified the threadStart
routine to call this routine before it returns. This means that
applications that use the dll version actually redundantly (but
harmlessly) call pthread_thread_detach_np() twice.

For statically linked applications this should mean that an
application should call two routines:

main()
{
  ...
  if (pthread_process_attach_np())
  {	
    ...
    pthread_process_detach_np();
  }
  else
  {
    /* No POSIX threads */
  }
  ...
  exit(0);
}

I have also modified the exception handling so that unhandled
exceptions are caught in order to allow pthread_destroy() to be
run before being rethrow (or returning EXCEPTION_CONTINUE_SEARCH
in the case of SEH).

One of the many clever things in John's original code was to
create automatic pthread instances for Win32 threads the first
time they call pthreads routines in order to interact with
POSIX threads. Thereafter those Win32 threads look like 
detached posix threads to the posix library. The only place
that the memory associated with these instances can be cleaned
up is in dllMain() since, of course, pure Win32 threads will never
return through ptw32_threadStart().

This means that, for statically linked applications, Win32 threads
should either:
- not interact with POSIX threads unless you are prepared
  to accept that resources will not be reclaimed until the
  application exits;
- arrange to call pthread_thread_attach_np() [currently a no-op]
  and pthread_thread_detach_np() from the dllMain of another
  dll library.
With regard to the second option, perhaps it may be worth
creating a dll containing only a dllMain with these calls in
place. The simple idea is that this pthreadInit.dll (or
something) be common to all compiler versions of the main
pthreads library and never change, and so avoid
the dll versioning problem. That is, an application would
link against two libraries: pthreadInit (DLL) and one of
pthreadVSE, pthreadVCE, or pthreadGCE (either DLL or static).

Comments?

Ross

"Bossom, John" wrote:
> 
> Sorry for the lag time... just got back from vacation...
> 
> You say you have an init and a close at the application level...
> How does this replicate the functionality of DLL_THREAD_ATTACH and
> DLL_THREAD_DETACH which are passed to DllMain every time a win32
> thread is created/destroyed?
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Laurence F. Wood [mailto:LaurenceWood@SunyataSystems.Com]
> Sent: December 22, 2000 4:00 PM
> To: Bossom, John; 'Mattias Ernelli'
> Cc: Pthreads Win32 (E-mail)
> Subject: RE: Memory leak problem in MSVS6.0 C RTL
> 
> I have implemented pthreads-win32 as a statically linked library.  As
> earlier described, the only thing that is necessary is to have two routines
> that are called prior to application init and close which replicate what the
> DLL would normally do.  We have tested this on some hairy massively threaded
> qauntum chemistry codes and it works fine.
> 
> -----Original Message-----
> From: pthreads-win32-owner@sources.redhat.com
> [mailto:pthreads-win32-owner@sources.redhat.com]On Behalf Of Bossom,
> John
> Sent: Friday, December 22, 2000 10:37 AM
> To: 'Mattias Ernelli'; Bossom, John
> Cc: Pthreads Win32 (E-mail)
> Subject: RE: Memory leak problem in MSVS6.0 C RTL
> 
> Like I said, if you do NOT the win32-pthreads DLL, you will not get the
> automatic
> cleanup of thread specific data (i.e. the destroy routine getting called on
> the
> data you registered with the key)...
> 
> -----Original Message-----
> From: Mattias Ernelli [mailto:Mattias.Ernelli@melody.se]
> Sent: December 22, 2000 10:28 AM
> To: 'Bossom, John'
> Cc: Pthreads Win32 (E-mail)
> Subject: RE: Memory leak problem in MSVS6.0 C RTL
> 
> Thanks for your quick reply.
> I noticed what caused the problem when I link pthreads with my application.
> I specify statically linked C RTL (libcmt/libcmtd) instead of dynamically
> linked (msvcrt/msvcrtd).
> 
> What happends is that the C RTL routines that uses the C RTL local storage
> allocates data on the fly, for example when accessing errno or rand(). The C
> RTL designers probably ensured that code calling CreateThread instead of
> _beginthreadex should not break.
> 
> If I build my application using dynamically linked C RTL, the memory leak
> goes away, probably because the RTL code that pthread calls to initialise
> the RTL thread data is different from the statically linked RTL functions
> that my application calls, and additionally data is allocated  by the
> statically linked C RTL code.
> 
> My question is then:
> 
> Is it possible to build the pthread-win32 library for statically linking?
> Booth regarding the linkage specification for the C RTL as well as
> pthreadXX.lib itself?
> 
> The reason for using statically linked libraries is in general that our
> application consists mainly of separate modules, each as a static library,
> each compiled using a static linkage specification for the C RTL, we could
> switch to dynamically linked C RTL, but I would prefer statically linked
> code. Its easier to keep things together and to avoid "dll hell"...
> 
> //Mattias
> 
> -----Original Message-----
> From: Bossom, John [mailto:John.Bossom@Cognos.COM]
> Sent: den 22 december 2000 13:56
> To: 'Mattias Ernelli'; Pthreads Win32 (E-mail)
> Subject: RE: Memory leak problem in MSVS6.0 C library when using
> pthread_c reat e
> 
> The code should be using beginthreadex and endthreadex... These
> interfaces ensure that the C RTL is initialized and cleaned up properly.
> If you do not use these thread routines and you attempt a C RTL call,
> you will probably blow up since C RTL initialization will not have
> taken place.
> 
> Now, the implementation of TSD for pthreads requires that you use the
> DLL version of pthreads... If you check the DllMain, you will see
> that it should, if DLL_THREAD_DETACH is passed, cause the TSD destroy
> routines to be called for this terminating thread, on all thread keys
> that have a destroy routine.
> If you are using the static link library for pthreads, you will have to
> perform this cleanup yourself.
> 
> -

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]