public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: "Aurelio Medina" <AMedina@xcaliber.com>
To: "Ross Johnson" <rpj@ise.canberra.edu.au>
Cc: <pthreads-win32@sources.redhat.com>, "Pat Bacon" <pbacon@xcaliber.com>
Subject: RE: Problem using PThreads TLS from a DLL.
Date: Thu, 07 Feb 2002 08:14:00 -0000	[thread overview]
Message-ID: <D5C377ECA6DD12478267E89585EE642C06C08C@chi-mail2.win.xcaliber.com> (raw)


I have found the real problem and a resolution for this problem.  I will summarize the problem and the solution that applies only if you are using the PThreads DLL from within another DLL.

Scenario:
[MY-APP] uses [MY-DLL] which uses [PTHREADS-DLL]

Problem:
For simplicity assume you have only one thread, that is the MY-APP/MY-DLL/PTHREAD-DLL address spaces are all within the same thread.
1) MY-APP implicitly loads MY-DLL and PTHREADS-DLL.
2) MY-DLL allocates TLS data (calloc()) and sets up a destructor (pthread_key_create()).
3) MY-APP does some work.
4) MY-APP calls exit().
5) MY-DLL is unloaded and therfore its address space is invalidated.
6) PTHREADS-DLL calls the TLS destructor on memory that was in MY-DLL's address space.
7) MY-APP crashes :(

Solution:
When MY-DLL receives a DLL_PROCESS_DETACH in DllMain() (i.e. Step 5) I free() the TLS data and unset the destructor (pthread_key_delete()).  Therefore when PTHREADS-DLL unloads it won't call my invalid destructor function which tries to delete invalid memory.  MY-DLL unloads before PTHREADS-DLL because it is dependent on it.

PS If you know of a better way please let me know.

Anyhow hope this may help others later,
Aurelio Medina

-----Original Message-----
From: Ross Johnson [mailto:rpj@ise.canberra.edu.au]
Sent: Wednesday, February 06, 2002 9:06 PM
To: Aurelio Medina
Cc: pthreads-win32@sources.redhat.com; Pat Bacon
Subject: Re: Problem using PThreads TLS from a DLL.


Aurelio Medina wrote:
> 
> Hello all,
> 
> I've encountered a problem when using the PThreads-Win32 (PThreadVCE)
> thread local storage (TLS) routines from within my own DLL.  Before I
> dig any deeper I would like to know if anyone has seen this and/or has
> a workaround.  My DLL is calloc'ing TLS data and I believe the TLS
> destructors (which I have calling free) are firing within the main app
> and not within my DLL.  This causes the app that uses my DLL to crash
> in the TLS destructor when calling free.  It crashes beacuse the app is
> trying to free CRT memory allocated by my DLL.   Is there some PThread
> function that I can call in my DLLMain to cause the TLS destructors to
> fire when my DLL is detached?

Do I understand the problem correctly: is this because the memory is
unallocated when your DLL is unloaded and therefore free()
segfaults?

Are you able to join those threads before unloading
your DLL? Pthread_join() will call the destructors
for you when the threads exit.

Ross

> 
> Thanks,
> Aurelio Medina

-- 
+-------------------------+---+
| Ross Johnson            |   | "Come down off the cross
| Management & Technology |___|  We can use the wood" - Tom Waits
| Building 11                 |
| University of Canberra      | eMail: rpj@ise.canberra.edu.au
| ACT    2601                 | WWW:  
http://public.ise.canberra.edu.au/~rpj/
| AUSTRALIA                   |
+-----------------------------+

             reply	other threads:[~2002-02-07 16:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-07  8:14 Aurelio Medina [this message]
2002-02-07  9:06 ` mmh
  -- strict thread matches above, loose matches on Subject: below --
2002-02-07 10:27 Aurelio Medina
2002-02-06  8:52 Aurelio Medina
2002-02-06 19:06 ` Ross Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D5C377ECA6DD12478267E89585EE642C06C08C@chi-mail2.win.xcaliber.com \
    --to=amedina@xcaliber.com \
    --cc=pbacon@xcaliber.com \
    --cc=pthreads-win32@sources.redhat.com \
    --cc=rpj@ise.canberra.edu.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).