This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
[Dr.Volker.Zell@oracle.com: Re: uxterm from xterm-185-3 and xfontsel crashing when running under cygserver support]
- From: Corinna Vinschen <vinschen at redhat dot com>
- To: cygwin-patches at cygwin dot com
- Cc: Thomas Pfaff <tpfaff at gmx dot net>
- Date: Tue, 30 Mar 2004 11:50:37 +0200
- Subject: [Dr.Volker.Zell@oracle.com: Re: uxterm from xterm-185-3 and xfontsel crashing when running under cygserver support]
- Reply-to: cygwin-patches at cygwin dot com
Hi Thomas,
----- Forwarded message from "Dr. Volker Zell" <Dr.Volker.Zell@oracle.com> -----
> Date: Tue, 30 Mar 2004 09:30:52 +0200
> From: "Dr. Volker Zell" <Dr.Volker.Zell@oracle.com>
> 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 <tpfaff@gmx.net>
[...]
(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?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin@cygwin.com
Red Hat, Inc.