| delorie.com/archives/browse.cgi | search |
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
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |