Mail Archives: cygwin/2009/10/15/11:54:21
Dave Korn wrote:
> Child gets started long enough to communicate with parent but then dies
> subsequently, still in early init, but late enough that the parent process
> create retries don't kick in. Don't hang about; get strace or procmon
> straight on the case with this, find out definitively if that process actually
> does get created or not. Oh, and maybe try a --enable-debugging build and set
> CYGWIN_DEBUG so you can intercept it if it does get started.
Well, here's where the complications of the real program kick in: it's a
daemon, which itself is earlier forked in order to dissociate with the
controlling terminal. At this point in the process, it's trying to
fork/exec a different program as a slave to do some work, and
communicate results back to the main process.
Anyway, because the daemon itself was earlier forked, I can't use
'strace <cmd line>' because that only traces the initial process, not
the daemonized one. If I launch <cmd line> and then attach strace to
the eventual pid of the daemonized process, it hangs (both strace and
the process). For some reason, if I launch the original program in
non-daemon mode, I can't get it to work at all, strace or not -- I'm
probably invoking it incorrectly, but I can't see how from the man page.
But that's what's so strange: whatever this is, occurs *after* the
fork() in the child -- if there IS a child -- but before the exec() of
the slave. So it's not like it can't find the slave program -- it
hasn't even looked yet...
I'm not familiar at all with procmon (sysinternals, right?) but I'll
look into it.
P.S. I fear I'm doing something wrong in my cygwin CVS builds, because
the last several times I have done so I've gotten weird behaviors after
installing the dll and .a -- /some/ newly built progs against the new
DLL die in weird ways, that do NOT occur when using the official
snapshots from the same source checkout. This just started happening
very recently, but I'm not sure what changed (this has nothing to do
with the recent pseudo-reloc stuff, because I rolled back to before that
and still see the same problem). So it's not the cygwin source code,
it's my build/install procedure somehow:
${src}/configure \
--srcdir=${src} --prefix=/usr \
--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib \
--includedir=/nonexistent/include \
--with-included-gettext
make CFLAGS="-ggdb -O0" tooldir=/usr && \
make info CFLAGS="-ggdb -O0" tooldir=/usr
make install prefix=$inst/usr exec_prefix=$inst/usr \
bindir=$inst/usr/bin libdir=$inst/usr/lib \
sysconfdir=$inst/etc includedir=$inst/usr/include \
tooldir=$inst/usr && \
make install-info prefix=$inst/usr exec_prefix=$inst/usr \
bindir=$inst/usr/bin libdir=$inst/usr/lib \
sysconfdir=$inst/etc includedir=$inst/usr/include \
tooldir=$inst/usr
...is what I've been doing, and it's worked for years until recently.
IIRC, it was taken by inspection of mknetrel, at some point in the
distant past. I notice that it differs from
http://cygwin.com/faq/faq.programming.html#faq.programming.building-cygwin
I do not have cocom installed, nor docbook-xml42, docbook-xsl, and xmlto.
Care to post your recipe, Dave? I'm sure it's more up-to-date than the
FAQ...
--
Chuck
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -