Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sources.redhat.com
Date: Mon, 13 Nov 2000 22:58:46 -0500
From: Christopher Faylor <cgf@redhat.com>
To: cygwin@cygwin.com
Subject: Re: XEmacs on cygwin wierdness
Message-ID: <20001113225846.A27122@redhat.com>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <3A0F7709.F8ED68FF@ece.gatech.edu> <20001113000953.A4917@redhat.com> <3A0F827C.15675931@ece.gatech.edu> <20001113010018.A6535@redhat.com> <3A0F9044.2E387F2F@ece.gatech.edu> <20001113115212.I7424@redhat.com> <3A10962B.1D0A386E@ece.gatech.edu> <20001113212846.B23184@redhat.com> <3A10B52B.47FFF093@ece.gatech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <3A10B52B.47FFF093@ece.gatech.edu>; from cwilson@ece.gatech.edu on Mon, Nov 13, 2000 at 10:44:43PM -0500

On Mon, Nov 13, 2000 at 10:44:43PM -0500, Charles Wilson wrote:
>Christopher Faylor wrote:
>> 
> >Okay, here's the results from XEmacs-21.2.36 (tarball, not from CVS)
>> >built under a latest-CVS-cygwin-debuggable kernel.  I apologize for not
>> >single-stepping this and investigating more thoroughly, but I've got a
>> >bunch of papers to grade tonight; I won't be able to return to this
>> >until tomorrow night at the earliest, but I figured I post my very
>> >preliminary experience
>> 
>> I really need to see a real stack trace to debug this.  From what you've
>> sent, it seems to me that this SIGSEGV has occurred in a process that
>> was invoked as a child of a shell.  That is counter to your original
>> bug report so something is screwy somewhere.
>
>???? I'll take a closer look tomorrow night...
>
>> 
>> Are you able to run anything with this DLL at all?  Is the gdb you
>> are using running the cygwin that you've built?
>
>Yes, I've installed the entire /usr/src/cygwin/inst/usr/* tree on top of
>my main installation.  gdb is running with the debug kernel, as is bash,
>rxvt, heck, *everything* is running with the debug kernel.

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?

It shouldn't be necessary but it almost looks like a DLL is being
invoked with its own 'environ' variable.  Cygwin tries to notice this
now and tries to synchronize multiple environ's.  However, if the
DLL initialized the 'environ' prior to cygwin seeing it, that
could cause problems.

It probably will have no effect, but could you try the patch?
This is against my modified version of cygwin so there will be
some skew when you apply it but it should still apply cleanly.
If not, you should be able to hand patch it.

cgf

Index: dcrt0.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/dcrt0.cc,v
retrieving revision 1.78
diff -u -p -r1.78 dcrt0.cc
--- dcrt0.cc	2000/11/11 05:36:34	1.78
+++ dcrt0.cc	2000/11/14 03:54:41
@@ -879,6 +880,7 @@ _dll_crt0 ()
 #endif
 
   main_environ = user_data->envptr;
+  *main_environ = NULL;
   user_data->heapbase = user_data->heapptr = user_data->heaptop = NULL;
 
   set_console_handler ();

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com