Re: [updated] Re: (patch) winsup noncygwin mess cleanup

[Chris Faylor <cgf at cygnus dot com>]

On Sun, Dec 05, 1999 at 02:10:29AM -0600, Mumit Khan wrote:
>Chris Faylor <cgf@cygnus.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