This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Dr.Volker.Zell@oracle.com: Re: uxterm from xterm-185-3 and xfontsel crashing when running under cygserver support]


On Mar 30 14:42, Thomas Pfaff wrote:
> Corinna Vinschen wrote:
> > 	void
> > 	pthread::atforkchild (void)
> > 	{
> > 	  __fp_unlock_all ();
> > 
> > 	  MT_INTERFACE->fixup_after_fork ();
> > 
> > 	  [...]
> > 	}
> > 
> > Can you explain this?  Is the fix correct?
> No.
> 
> The problem is caused by cygrunsrv which is started by the service control
> manager.
> Because of this it does not have a properly initialized mainthread. When it
> locks a mutex the owner will be the pthread_null instance.After the fork the
> child will be reinitialized and the pthread_self pointer is changed,
> therefore it is no longer able to unlock a mutex which was locked by its parent.
> 
> I think that there are 2 possible workarounds:
> 
> 1. The thread which is started by the service control manager must be
> initiallized, for example in the first get_tls_self_pointer call. Chris has made
> some changes to TLS, i do not know if _my_tls  can be used for a thread that is
> created from outside.

But that can't be caused by being started by the SCM.  In theory, the
situation should be equivalent for each process started by a non-cygwin
process, isn't it?

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.


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