Re: dtable changes causing _very_ slow startup and process-startup headache. [was Re: auto-import ld]

[Christopher Faylor <cgf at redhat dot com>]

On Thu, Jun 07, 2001 at 11:08:56PM +1000, Robert Collins wrote:
>Hi folk,
>    some background first... When I recently upgraded my source tree to
>current, to pickup on my pthreads work, I found that cygwin process's
>launched from non-cygwin process take up to 30 seconds to _start_
>running.
>
>A strace on the program (say df) when launched from cmd.exe shows this
> 577  136584 [main] df 1764 environ_init: 0xA010F10: WINDIR=E:\WINNT
> 683  137267 [main] df 1764 pinfo_init: pid 1764, pgid 1764
> 416  137683 [main] df 1764 dtable::extend: size 32, fds 0x1A020090
>as the last output before the delay occurs.
>
>I haven't looked into this, as I actually thought it was some of my code
>for a while, until tonight when I dropped the 4th June snapshot on, and
>saw it wasn't my fault :].
>
>A similar-in-appearance problem is occuring with binaries linked by a
>patched ld.exe, (which I just installed tonight, so the first thing is
>not an artifact of that). I'm trying out Paul Solovosky{I hope thats
>right}'s ld-that-auto-imports.
>
>The symptoms there are that with cygwin 1.3.2, and with the 4th June
>snapshot, the trivial test case (one .dll with exported DATA and
>functions, one dependant program, about 20 lines of code) locks up the
>CPU at 100%. It then dies with an illegal memory access at 0x00000010.
>
>Whats interesting about that fault is that running the test case
>"client.exe" from cmd.exe/gdb/strace with the same cygwin1.dll works!.
>(And cygwin already in-memory in another window.)
>
>So, I'm really whining about 2 things, and probably should have written
>two emails!.
>
>1) dtable::extend causing large delays on startup (I have no net mapped
>drives, before you ask) and
>2) cygwin process initialisation killing patched-ld-linked apps that run
>fine in all other respects.
>
>=== pause during message composition ===
>
>I just updated and rebuilt cygwin, and tried again... no joy with either
>issue. I can't say why, but I have a suspicion that they are related...
>
>Any clues?

What clues are you hoping for that wouldn't be immediately apparent from
running gdb on this?  If there is a substantial delay, it should be really
easy to figure out where this is.

cgf