Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-developers-unsubscribe-archive-cygwin-developers=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Date: Sun, 5 Dec 1999 12:48:11 -0500
From: Chris Faylor <cgf AT cygnus DOT com>
To: Mumit Khan <khan AT nanotech DOT wisc DOT edu>
Cc: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: [updated] Re: (patch) winsup noncygwin mess cleanup
Message-ID: <19991205124811.A720@cygnus.com>
Mail-Followup-To: Mumit Khan <khan AT nanotech DOT wisc DOT edu>,
	cygwin-developers AT sourceware DOT cygnus DOT com
References: <19991204214552 DOT A10152 AT cygnus DOT com> <199912050810 DOT CAA01923 AT mercury DOT xraylith DOT wisc DOT edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <199912050810.CAA01923@mercury.xraylith.wisc.edu>; from khan@nanotech.wisc.edu on Sun, Dec 05, 1999 at 02:10:29AM -0600

On Sun, Dec 05, 1999 at 02:10:29AM -0600, Mumit Khan wrote:
>Chris Faylor <cgf AT cygnus DOT com> writes:
>> Hmm.  The stdin/out fds should be opened in hinfo_init since parent_alive
>> should be NULL.  Is parent_alive non-NULL for some reason?
>
>The trouble was in pinfo_init. We have to pretend not have a parent
>process to take stuff from when dynamically loaded. I also force
>parent_alive to NULL in that case just to be safe.

Hmm.  I guess if a process which dynamically loads cygwin is started by
a cygwin process it should be able to inherit the fds correctly.  I'll
have to think about this.

>> I don't think it's really important.  But, of course, if we don't do
>> it, the first question on the cygwin mailing list after your patch is
>> applied will be something like "I'm trying to get my GLIP application
>> running using the snapshot from 12/7 and now I can't send any signals.
>> What gives?"
>
>I'm running into bizarre segfaults *after* the DLL is initialized when
>signals are enabled. Since I can't use gdb in this case, it's rather
>hard to debug. There's also the issue of threading here (I'm testing
>this with Java JNI), so I'm going to punt on this issue for now.

You can always attach to the running process.  You can also use the
"error_start" CYGWIN setting.  If you set

set CYGWIN=error_start=c:\bin\gdb.exe

It will pop up a gdb automatically.  I think that this should still work
in the dynamically loaded case.

>Here's an updated patch that fixes the stylistic issue as well as
>the missing stdout/err issue when exec'd from a Cygwin app. The two
>new and small changes are in dcrt0.cc:dll_crt0_1.

I'll apply this ASAP.  Thanks.

cgf