Trying to find a solution for segmentation fault crashes in the most recent x server provided by setup.exe

Trying to find a solution for segmentation fault crashes in the most recent x server provided by setup.exe

[Larry W. Virden]

So, after several hours more of investigation, I discovered that while
gdb was installed on my machine, it was not installed on the machine
where we were testing. I installed it there, but the crash still
occurs. The backtrace produced is quite huge - and less useful because
X didn't have any of the debugging symbols in it.

here is a bit of what we are seeing.

We start up the X server. It is configured to use xauth.
We start up a mintty session and an xterm session.
We ssh from these windows to our SPARC Solaris 9 work machines.
We start up, in each window, an in-house written binary application
which makes use of the Tk C libraries.

If we run just 1 mintty, or just 1 xterm, that works.
If we run one of each (which the developers do due to various
features, etc. they wish to leverage), we often - not always - get an
error of the following nature.

GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)

This GDB was configured as "i686-cygwin".



==================== Backtrace ================



Thread 25 (Thread 5368.0x1704):

#0  0x775e000d in ntdll!LdrFindResource_U ()

   from /cygdrive/c/Windows/SysWOW64/ntdll.dll

No symbol table info available.

#1  0x7766f896 in ntdll!RtlQueryTimeZoneInformation ()

   from /cygdrive/c/Windows/SysWOW64/ntdll.dll

No symbol table info available.

#2  0x70d9aec6 in ?? ()

No symbol table info available.

:
and so on
:

Thread 24 (Thread 5368.0x1b24):

#0  0x775ef8b1 in ntdll!RtlUpdateClonedSRWLock ()

   from /cygdrive/c/Windows/SysWOW64/ntdll.dll

No symbol table info available.

#1  0x775ef8b1 in ntdll!RtlUpdateClonedSRWLock ()

   from /cygdrive/c/Windows/SysWOW64/ntdll.dll

No symbol table info available.

#2  0x762f0a91 in WaitForSingleObjectEx ()

   from /cygdrive/c/Windows/syswow64/KERNELBASE.dll

No symbol table info available.

#3  0x000007a4 in ?? ()

No symbol table info available.

:
and so on
:

Thread 23 (Thread 5368.0x1590):

#0  0x775efd71 in ntdll!RtlFindSetBits ()

   from /cygdrive/c/Windows/SysWOW64/ntdll.dll

No symbol table info available.

#1  0x762f31bb in SleepEx () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll

No symbol table info available.

#2  0x00000000 in ?? ()

No symbol table info available.



Thread 22 (Thread 5368.0x1a20):

#0  0x775f013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()

   from /cygdrive/c/Windows/SysWOW64/ntdll.dll

No symbol table info available.

#1  0x775f013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()

   from /cygdrive/c/Windows/SysWOW64/ntdll.dll

No symbol table info available.

#2  0x762f0bdd in WaitForMultipleObjectsEx ()

   from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
:
and so on
:

Thread 21 (Thread 5368.0x18f4):

#0  0x775ef8e5 in ntdll!RtlUpdateClonedSRWLock ()

   from /cygdrive/c/Windows/SysWOW64/ntdll.dll

No symbol table info available.

#1  0x775ef8e5 in ntdll!RtlUpdateClonedSRWLock ()

   from /cygdrive/c/Windows/SysWOW64/ntdll.dll

No symbol table info available.

#2  0x762ed348 in ReadFile () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll

No symbol table info available.

#3  0x00000794 in ?? ()

:
and so on
:
many more threads and finally
:

Thread 1 (Thread 5368.0x1bec):

#0  0x775f013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()

   from /cygdrive/c/Windows/SysWOW64/ntdll.dll

No symbol table info available.

#1  0x775f013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()

   from /cygdrive/c/Windows/SysWOW64/ntdll.dll

No symbol table info available.

#2  0x762f0bdd in WaitForMultipleObjectsEx ()

   from /cygdrive/c/Windows/syswow64/KERNELBASE.dll

No symbol table info available.

#3  0x00000003 in ?? ()

No symbol table info available.

:
and so on
:

Backtrace stopped: previous frame inner to this frame (corrupt stack?)



==================== Backtrace End ============



[  3569.256] Segmentation fault at address 0x65682e91

[  3569.256]

Fatal server error:

[  3569.256] Caught signal 11 (Segmentation fault). Server aborting

[  3569.256]

[  3569.256] Server terminated with error (1). Closing log file.


Note that in several of the skipped portions above there were lines such  as

Backtrace stopped: Not enough registers or memory available to unwind further


The log file is 45K, so I didn't include it completely until I hear
back that someone would find it useful


--
Tcl - The glue of a new generation.   http://wiki.tcl.tk/
Larry W. Virden
http://www.facebook.com/lvirden/
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

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

Re: Trying to find a solution for segmentation fault crashes in the most recent x server provided by setup.exe

[Larry W. Virden]

Well we continue to discover new things about our specific situation
with xfree server crashes.

This may in fact be a general cygwin problem rather than xfree. What
we are finding is a change in general process handling.

During our original testing - on windows 7 32-bit - we tested scripts
we had developed under XP that prompt the user for information about
the server, login, etc. and then start the x server and invoke the
cygwin xterm or mintty to perform an ssh -Y to the server as the login
specified.
The code looked at the processes, identified whether or not the server
was running, and, if not, launches a new server. Otherwise, the code
skips that step and goes on to start the terminals.

After testing, a deployment decision was made to move to windows 7 64 bit
 instead.

We assumed that everything would continue to work as tested.

What we are seeing, now however, is that we are getting multiple X
servers started. Even worse, we are seeing processes like bash, ssh,
mintty, and xterm hanging around after the user has closed the
windows.

We are looking into why the script is no longer seeing the X server
process running.

But the fact that those processes are sticking around after the
windows are closed seems to be an issue.

Anyways, as soon as someone tries to use windows attached to more than
one of the running X servers, then we see crashes. Not all the servers
crash, which really caused us a lot of confusion - we would get error
messages saying the server had crashed, but occasionally xterms would
still be running, etc.

I am a bit surprised that the X server itself doesn't prevent someone
from starting a second version on the same cpu/disk/cygwin instance.
But perhaps there is some use for that kind of special functionality.

Has anyone else seen similar behaviors?

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