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]


Corinna Vinschen wrote:
> 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?
> 

Regardless whether a process is started from a cygwin app or not it will
always start at mainCRTStartup. 

When it is started by the SCM however the service_main thread is created by
the SCM. The situation is similar to calling CreateThread instead of
pthread_create. The thread will be handled as anonymous since it is not in the thread
list and has not been initialized in thread_init_wrapper.

I think the easiest way is to modify pthread::init_mainthread in a way that
it handles such a situation properly and will keep the pthread_self pointer
unchanged after a fork.

But you can also change cygrunsrv to create a thread via pthread_create and
fork from this thread. This should work either.

Thomas

-- 
+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz


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