This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
Re: [Dr.Volker.Zell@oracle.com: Re: uxterm from xterm-185-3 and xfontsel crashing when running under cygserver support]
- From: "Thomas Pfaff" <tpfaff at gmx dot net>
- To: cygwin-patches at cygwin dot com
- Date: Tue, 30 Mar 2004 14:42:20 +0200 (MEST)
- Subject: Re: [Dr.Volker.Zell@oracle.com: Re: uxterm from xterm-185-3 and xfontsel crashing when running under cygserver support]
Corinna Vinschen wrote:
> ----- Forwarded message from "Dr. Volker Zell" -----
> > Date: Tue, 30 Mar 2004 09:30:52 +0200
> > From: "Dr. Volker Zell"
> > Subject: Re: uxterm from xterm-185-3 and xfontsel crashing when running
> > under cygserver support
> > To: cygwin-xfree@cygwin.com
> > Reply-To: cygwin-xfree@cygwin.com
> >
> > >>>>> "Corinna" == Corinna Vinschen writes:
> >
> > Corinna> I've build my own debug version of the X stuff today and I
tracked the
> > Corinna> SEGV down. It's an unfortunate combination of two bugs in
the SHM
> > Corinna> implementation:
> > [...]
> >
> > I just tried your fix which seems to be in the 20040329 snapshot. But
> > now /usr/sbin/cygserver doesn't start anymore. I installed it as a
> > service with cygrunsrv. The same happens for my other cygwin service
> > /sbin/init which also refuses to start. In the process list I could see
> > 4 !! /bin/cygrunsrv processes so. Reverting to 1.5.9 and all is fine.
> ----- End forwarded message -----
>
> I've tracked down this problem to the point that I know what change has
> introduced this problem. It happens with all snapshots since 20040326
> and the change was this one:
>
> 2004-03-26 Thomas Pfaff
>
> [...]
> (pthread::atforkprepare): Lock file pointer before fork.
> (pthread::atforkparent): Unlock file pointer after fork.
> (pthread::atforkchild): Ditto.
>
> More exactly, the problem happens in pthread::atforkchild ():
>
> void
> pthread::atforkchild (void)
> {
> MT_INTERFACE->fixup_after_fork ();
>
> __fp_unlock_all ();
>
> [...]
> }
>
> where it hangs in fixup_after_fork(). When turning around the order
> of the above two commands, evrything seems to work fine:
>
> 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.
2. The pthread_self pointer should never change after a fork.
This requires some changes in pthread::init_mainthread. If
get_tls_self_pointer returns NULL pthread_null::_instance should be used instead of creating
a new thread object.
Thomas
--
+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz