This is the mail archive of the
cygwin-developers@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: [updated] Re: (patch) winsup noncygwin mess cleanup
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