[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Enable runtime cwrapper debugging; add tests
From: |
Charles Wilson |
Subject: |
Re: [PATCH] Enable runtime cwrapper debugging; add tests |
Date: |
Sun, 10 Jan 2010 21:54:01 -0500 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 |
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?
>> Oh yeah...ping? Is the HPUX problem a blocker for these three patches,
>
> No.
Good!
>> 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.
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.
...
Unfortunately, I don't see a way to avoid this problem on HP/UX -- short
of requiring a less brain-dead shell.
1. every HERE document creates a temp file, whether that HERE document
should or should not be emitted by the script. If the script
contains the magic <<EOF...EOF incantation even if it's inside an
excluded block:
if /bin/false; then
cat >foo <<-EOF
blah blah
EOF
fi
We may not get a file named 'foo' but we WILL get a temp file, whose
name we do not know, with the contents 'blah blah'.
2. there are only a limited number of unique temp file names
3. Sometimes these temp files don't get cleaned up. Eventually, we will
try to reuse the temp file name of one of these non-cleaned pieces
of litter. Boom.
We can't even pre-emptively clean up the temp files "as the first line
of the script on HP/UX" -- because we'd be "cleaning up" the ones
produced by parsing of THIS instance of the script -- some of which we
may actually need -- not to mention possibly others needed by other
in-progress instances. What a mess.
--
Chuck