#119 Access violation due to changed usage of pthreads-win32

[Klaus Fischer]

Dear libupnp developers,

I have experienced a crash (access violation) when using libupnp on Windows. The crash is actually located in pthreads-win32 and happens when repeatedly de-/initializing libupnp on Win32 in the same process and both libupnp and pthreads-win32 are compiled as static libraries.

So I'm doing this:
- UpnpInit()
- UpnpFinish()
- UpnpInit() <- Crash

I am already in touch with Ross Johnson on the pthreads-win32 mailing list regarding this issue:
http://sourceware.org/ml/pthreads-win32/2013/msg00020.html

He told me the problem is that the functions pthread_win32_process_attach/detach_np() should no longer be called directly, but are invoked automatically now since version 2.9.0 of pthreads-win32, which has been released approx. 1.5 years ago. Please refer to above link for in-depth information.

So for proper using of latest pthreads-win32 library, those function calls should vanish inside libupnp. Could you consider adapting libupnp in that way? I would really like to use both libraries out-of-the-box without local modifications, and this issue prevents that.

Best regards,
Klaus

[Marcelo Roberto Jimenez]

Hi Klaus,

I can do the necessary changes, but I personally cannot test for the lack of a windows system, so I need your collaboration on the issue.

From what I can read in pupnp sources, up to now these functions are only called on a win32 static build. They have never been called on a dynamic build. In this case, the modification consists simply of removing the call completely from the code.

Please check if the attached patch solves the issue and report back so that I can commit it.

Regards,
Marcelo.

[Klaus Fischer]

Hi Marcelo,

thanks for your quick response!

I have applied your patch but am facing a hang-up now, which is caused
by a call to pthread_cond_wait() of the pthreads-win32 library. This
didn't occur when the initialization of pthreads-win32 was in place, as
previously.

I'm trying to figure out what's wrong with Ross over at sourceware.org
and let you know when we have reached a conclusion!

Best regards,
Klaus

On 07.11.2013 19:52, Marcelo Roberto Jimenez wrote:

Hi Klaus,

I can do the necessary changes, but I personally cannot test for the lack of a windows system, so I need your collaboration on the issue.

From what I can read in pupnp sources, up to now these functions are only called on a win32 static build. They have never been called on a dynamic build. In this case, the modification consists simply of removing the call completely from the code.

Please check if the attached patch solves the issue and report back so that I can commit it.

Regards,
Marcelo.

Attachment: sf-bugs-199.patch (701 Bytes; text/x-patch)

---

[bugs:#119] Access violation due to changed usage of pthreads-win32

Status: open
Labels: pthreads static win32
Created: Thu Nov 07, 2013 03:55 PM UTC by Klaus Fischer
Last Updated: Thu Nov 07, 2013 03:55 PM UTC
Owner: Marcelo Roberto Jimenez

Dear libupnp developers,

I have experienced a crash (access violation) when using libupnp on Windows. The crash is actually located in pthreads-win32 and happens when repeatedly de-/initializing libupnp on Win32 in the same process and both libupnp and pthreads-win32 are compiled as static libraries.

So I'm doing this:
- UpnpInit()
- UpnpFinish()
- UpnpInit() <- Crash

I am already in touch with Ross Johnson on the pthreads-win32 mailing list regarding this issue:
http://sourceware.org/ml/pthreads-win32/2013/msg00020.html

He told me the problem is that the functions pthread_win32_process_attach/detach_np() should no longer be called directly, but are invoked automatically now since version 2.9.0 of pthreads-win32, which has been released approx. 1.5 years ago. Please refer to above link for in-depth information.

So for proper using of latest pthreads-win32 library, those function calls should vanish inside libupnp. Could you consider adapting libupnp in that way? I would really like to use both libraries out-of-the-box without local modifications, and this issue prevents that.

Best regards,
Klaus

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/pupnp/bugs/119/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

--

---

Dipl. Inf. Klaus FISCHER - Software Engineer

 mailto: klaus.fischer@tara-systems.de

TARA Systems GmbH | Tel: +49 89 747121 37
Gmunder Str. 53 | Fax: +49 89 747121 20
81379 Munich - Germany | http://www.tara-systems.de

---

Registered as HRB 103149 at Munich Local Court
Managing Director: Dipl.Ing. A. Wass

[Klaus Fischer]

Hi Marcelo,

thanks for your quick response!

I have applied your patch but am facing a hang-up now, which is caused by a call to pthread_cond_wait() of the pthreads-win32 library. This didn't occur when the initialization of pthreads-win32 was in place, as previously.

I'm trying to figure out what's wrong with Ross over at sourceware.org and let you know when we have reached a conclusion!

Best regards,
Klaus

[Klaus Fischer]

Hi Marcelo,

sorry for the delay. I finally came to a working solution in this issue now: The problem was that I used a custom build process for building pthreads-w32 that didn't include the functionality for automatically calling the pthread_win32_process_attach/detach_np() functions, so pthread-w32 wasn't initialized at all. I'm using the delivered Nmakefile now, which compiles this functionality into the pthreads-win32 library.

Applying your patch afterwards worked, so it would be great if I could see it in a future version of libupnp!

Best regards,
Klaus

[Marcelo Roberto Jimenez]

Hi Klaus,

I have committed the patch, it will be on the next release.

Regards,
Marcelo.