Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Wed, 11 Jun 2003 12:05:51 +0200
From: Rasmus Hahn <rassahah AT neofonie DOT de>
To: Thomas Pfaff <tpfaff AT gmx DOT net>
Cc: cygwin <cygwin AT cygwin DOT com>
Subject: Re: Problem w/ c++,threads,static initializers
Message-ID: <20030611120551.A3205@hamburg.neofonie.local>
References: <20030607142449 DOT A4909 AT hamburg DOT neofonie DOT local> <3EE587F7 DOT 9090405 AT gmx DOT net> <20030611080702 DOT A1768 AT hamburg DOT neofonie DOT local> <3EE6CF20 DOT 7070005 AT gmx DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3EE6CF20.7070005@gmx.net>; from tpfaff@gmx.net on Wed, Jun 11, 2003 at 08:41:36AM +0200


Hi Thomas,

Problem solved: it was not the mutex but the but the pthread_mutexattr_t
that caused the error. cygwin's pthread_mutexattr_init () function checks
if its argument points to a valid object. If the pthread_mutexattr_t's 
value still points to a valid object (from a previous call)
pthread_mutexattr_init () fails, and so do later pthread_mutex_init()s with
this attribute. I think this behaviour is not correct since an uninitialized
pthread_mutexattr_t can point to anything (as a previously created attribute),
so this is probably a bug in cygwin (or what does the International Pthread
Attributes Committee say?). A quick look in winsup/cygwin/thread.cc shows
that this kind of check is done for more of the ..._init() functions, so there
may be similar effects (but i did not test that yet). Demo-Program below does
not work with (my) cygwin but does in my linux box:

#include <pthread.h>
int main () {
  pthread_mutexattr_t attr;
  pthread_mutexattr_init (&attr);
  if (pthread_mutexattr_init (&attr)) {
    printf ("error should not happen\n");
  }
}

Greetings - Rasmus


> Rasmus Hahn wrote:
> > On Tue, Jun 10, 2003 at 09:25:43AM +0200, Thomas Pfaff wrote:
> > 
> >>Rasmus Hahn wrote:
> >>
> >>
> >>>Hello,
> >>>
> >>>i am using cygwin on my Windows2000 and my c++ program segfaults
> >>>when using pthread-mutexes. In particular i am using a lot of
> >>>mutexes from within constructors of static objects. These constructors
> >>>are called at a very early time of execution of the program and do
> >>>calls of pthread_mutex_init, pthread_mutex_lock and such. Taken a glance
> >>>at the cygwin source i noticed that the static initializers (constructors
> >>>of static objects) are run _before_ some user_data->threadinterface is
> >>>initialized (look at dll_crt0_1 () in winsup/cygwin/dcrt0.cc). Isnt it 
> >>>possible to use thread-functions from static initializers?
> >>>BTW i am using cygwin snapshot 20030602 compiled with gcc-3.3 since the
> >>>out-of-the-box gcc from the cygwin-package is a prerelease and definitely
> >>>contains bugs that do not allow it to compile my code.
> >>>
> >>
> >>Could you provide a test case ?
> > 
> > 
> >   No, i cannot. As it turned out the initializers are run at least but i
> >   dont know if before or after cygwin-initialization. Only when run with
> >   gdb the program behaves differently (crash in constructors). That makes
> >   reproduction & location of errors a little harder.
> > 
> 
> If your program only segfaults in the debugger than the problem is a
> harmless IsBadWritePtr which is used to check for an already initialized
> mutex.
> You can ignore this one. Set a breakpoint at main and continue.
> To avoid it you can set the mutex to PTHREAD_MUTEX_INITIALIZER before
> you call pthread_mutex_init.
> 
> Thomas
> 
> 
> 

-- 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/