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

[Ralf Wildenhues]

* Charles Wilson wrote on Mon, Jan 11, 2010 at 03:54:01AM CET:
> Ralf Wildenhues wrote:
> > That's not how these ancient shells work.
> [snip long explanation]
> 
> Oh, that's just...evil.  How could that EVER have been expected to work
> properly, except in the most trivial of scripts?

Good question.

> >> 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.
> 
> Well, that's...good, I suppose. It means that the problem isn't
> specifically in the fork/shell-func/HERE implementation, such that the
> failure ALWAYS occurs.  But instead, it means that we have a race
> condition or resource contention problem (where 'unique names' can be
> considered a resource) -- or maybe my test case wasn't sufficiently
> complex, and didn't capture the bug exposed by libtool-as-a-whole.

We have a combination of shell bugs, not all of which we can
characterize exactly, and we try to not trigger them more than
necessary.

Let's not worry about this too much for now.  If it turns out to be a
big problem in practice, we will receive bug reports.  If somebody (me)
gets overly ambitious, I'll add some printf's to find out whether we are
triggering leftover temporaries only in specific cases.  Without such
data I wouldn't bother searching any further, though.

> Unfortunately, I don't see a way to avoid this problem on HP/UX -- short
> of requiring a less brain-dead shell.

Well, even just characterizing a broken shell is a problem if you don't
know exactly what the problem is.


Bottom line of all this is merely that we always have to expect trouble
on some other systems.

For an unrelated anectode: AIX has the nice habit of caching some shared
objects (with suitable permissions) in-memory even after process
termination, such that subsequent processes using the same library are
started faster.  During Libtool testsuite run, this happens for some
libraries in the build tree.  My test hosts mostly have their trees on
NFS, which refuses to erase directories with files that are still in use
somewhere.  Result: the testsuite cannot clean up after itself.  This
frequently causes hiccups and spurious testsuite failures for Libtool.
I usually just move the toplevel testsuite.dir away and remove it a year
later, when the system is sure to have been rebooted, or ask the
operator to run slibclean at her convenience.

Cheers,
Ralf