Re: [PATCH] Enable runtime cwrapper debugging; add tests

[Ralf Wildenhues]

Hello Charles,

* Charles Wilson wrote on Wed, Dec 23, 2009 at 09:28:49PM CET:
> Ralf Wildenhues wrote:
> > * Charles Wilson wrote on Mon, Dec 14, 2009 at 06:47:10PM CET:
> >> Finally, it's not clear in your message: are you saying that *existing*
> >> win32 "changes" currently in master are causing problems on HP-UX, or
> >> just that some of the win32 changes /in this patch/ are causing them?
> > 
> > Something causes lots of leftover shell temp files, and they contain
> > cwrapper contents.  These leftover files cause later, unrelated
> > processes with same PIDs to fail when needing shell temp files as well
> > (yeah the temp file naming is really crappy).  Bet it's merely some
> > shell bug with here-documents in functions or so, but I haven't analyzed
> > it yet.
> 
> Hm. Platforms that are not win32ish should not be emitting the cwrapper
> at all.

That's not how these ancient shells work.  They actually go ahead and
write out the contents of here-documents to a temp file at parse time,
not just at execution time.  Then, some, like AIX /bin/sh, even start
producing hard-links whenever they fork a subshell or so.  This was one
of the reasons that

for var in list; do
  some very long script text with subshells ...
  cat <<\EOF
...
  EOF
  more script text ...
done

caused such an immense churn in 1.5.x libtool: the shell would be busy
with link/unlink for any fork that happened during the script parts in
the loop.

I'm not sure whether it's the same thing happening on HPUX; but what I
see is that, in addition to creating actual files for here-documents,
the shell also has the misfeature of using very predictable file names.

Then, sometimes, there would be leftover files from these here-documents.
I'm not sure whether they originate only in fatal shell errors from
buggy scripts, or there are simply more bugs in /bin/sh.

Taken together, and with the me spawning full testsuite runs for the
autotools packages on such a system, and each of them has its share of
a few thousand shell invocations, and failures due to name collisions
turn out to be fairly common, causing the respective script to barf,
and tests to fail.

'info Autoconf Here-Documents' has some more information on this, and
Sven Mascheck's pages somewhere document another bug with non-literal
content in them (worked around by putting the here-doc inside an eval).

> Oh yeah...ping? Is the HPUX problem a blocker for these three patches,

No.

> or can they be considered before solving the HPUX issue?

> In any case, here's a quick-n-dirty set of test scripts to help narrow
> down the problem.  If someone with access to HPUX can unpack and run
> 't.sh', and report back the results, we might be able to narrow down the
> cause of this problem. (Might need to change the shbang lines to use the
> same shell that's causing issues with libtool).

The tests all pass with HP-UX /bin/sh and /bin/ksh.

Cheers,
Ralf