Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Sun, 19 Jan 2003 12:19:26 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-xfree AT cygwin DOT com, cygwin AT cygwin DOT com
Subject: Re: Crash on startup - debugging info
Message-ID: <20030119171926.GC22838@redhat.com>
Reply-To: cygwin-xfree AT cygwin DOT com, cygwin AT cygwin DOT com
Mail-Followup-To: cygwin-xfree AT cygwin DOT com, cygwin AT cygwin DOT com
References: <NHEELHJHHFKPMAEAFMFCIEJJDFAA DOT huntharo AT msu DOT edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <NHEELHJHHFKPMAEAFMFCIEJJDFAA.huntharo@msu.edu>
User-Agent: Mutt/1.5.1i

On Sun, Jan 19, 2003 at 02:47:31AM -0500, Harold L Hunt II wrote:
>Okay, there are at least two problems happening in XWin.exe.
>
>The first problem is totally unrelated to the new multiwindow mode.  The
>problem is, if you startup XWin.exe in gdb, a call to fchown causes a
>SIGSEGV on every single execution.  That sucks.
>
>You can avoid that problem by setting a break in
>_XSERVTransSocketUNIXCreateListener, then stepping until right before the
>call to fchown, then ``set updateOwner=0'', which causes the call to be
>skipped.  After that you can continue.  In non-multiwindow mode the server
>will run fine after the continue.
>
>
>The second problem is that in multiwindow mode the call to
>pthread_mutex_init causes a SIGSEGV.  That sucks too.  I have peeked at the
>code for pthread_mutex, but I can't figure out much.  I might eventually
>have to setup a cygwin1.dll build environment so I can debug this, but I
>would really like to avoid that if possible.  I actually started building a
>debug version of cygwin1.dll tonight, but I got to the part where it needs
>libiberty and I wussed out.

Have you tried continuing beyond the SIGSEGV?  Some of the pthread code
does a check of invalid memory and ends up raising an exception that is
caught by the debugger.  Unfortunately, there isn't much that gdb can do
to detect that situation so we're stuck just continuing in that scenario.
If a continue ends up leaving you in the same place then it really is a
SIGSEGV.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/