Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3A14545E.445FE34F@ece.gatech.edu>
Date: Thu, 16 Nov 2000 16:40:46 -0500
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: XEmacs on cygwin wierdness
References: <3A0F827C DOT 15675931 AT ece DOT gatech DOT edu> <20001113010018 DOT A6535 AT redhat DOT com> <3A0F9044 DOT 2E387F2F AT ece DOT gatech DOT edu> <20001113115212 DOT I7424 AT redhat DOT com> <3A10962B DOT 1D0A386E AT ece DOT gatech DOT edu> <20001113212846 DOT B23184 AT redhat DOT com> <3A10B52B DOT 47FFF093 AT ece DOT gatech DOT edu> <20001113225846 DOT A27122 AT redhat DOT com> <3A121018 DOT CAA2139D AT ece DOT gatech DOT edu> <3A123D94 DOT 90D09BD4 AT ece DOT gatech DOT edu> <20001116154956 DOT B23051 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Christopher Faylor wrote:
> 
> On Wed, Nov 15, 2000 at 02:39:00AM -0500, Charles Wilson wrote:
> >"Charles S. Wilson" wrote:
> >>
> >> Christopher Faylor wrote:
> >> >
> >> > The more I think about this, the more I think that your stack trace
> >> > should actually be impossible.  It looks like a pointer that should be
> >> > zero isn't.  Out of curiousity, does the patch below cause any
> >> > difference?
> >>
> >> Yes, that fixes it.  Now I can run xemacs (without recompiling *it*)
> >> from cmd.exe or from bash.  No problems. However, obviously there is
> >> something wacky going on with xemacs; unfortunately, I don't understand
> >> the wacky structure of xemacs.exe well enough to debug it
> >> authoritatively.
> >>
> >> I'll give it a shot and report back....
> >
> >Well, I'm not sure why, but I can't single-step XEmacs and gdb doesn't
> >recognize any breakpoints prior to the bomb.  I can only "run" and then
> >investigate after the crash.
> 
> That sounds like Xemacs is either forking or execing a new process.  That
> would also explain why main_environ had "stuff" in it but now why environment
> handling was getting confused.
>
> Was there any further resolution on this, Chuck?  

No, I had to take a break and get some real work done.  I was hoping
that some XEmacs-NT guru on the xemacs-nt list would take an interest,
but no luck there except for Andy.  He pointed out a few things to try
such as using the cvs version of xemacs.  However, the suggestions
didn't help as there were other *compile time* errors with
xemacs-nt-cvs.  Sigh.

As I've said before, I'm not familiar with the guts of xemacs, and don't
want to *become* a guru on xemacs-nt.  I just wanted to use it -- and it
provided a convenient vehicle for verifying my xpm libraries and ncurses
libraries.  

*That* part, at least, has been worthwhile -- it seems that my xpm and
ncurses libs are, in fact, okay. This error is independent of those
libs, and is either a problem with XEmacs itself, or cygwin's startup
code, or both.

Since setting *main_environ = NULL within dcrt0.cc fixes the problem, is
there any reason NOT to include that fix in cygwin?

> One other thing you can do
> is 'set CYGWIN=error_start_init=x:\path\to\gdb.exe' to have cygwin start gdb
> automatically when an error occurs.

I tried that -- but xemacs "successfully" crashed while cygwin did NOT
start up gdb.

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com