Hi Jack, I believe the --save-temps command line option will give your
the paper trail that you want here, could you give that a try? Do this
on a machine with plenty of free disk space.
The version of the file being reduced that is in the original location
where you invoked C-Reduce is guaranteed (unless C-Reduce contains bugs,
but we know of no such bug) to have passed the interesting test once.
But the probability may be very low. My guess is that is what happened
to you: the test became less and less likely to pass, but it happened to
pass and the file got copied over.
The real answer here is to avoid nondeterminism, for example by
disabling ASLR on your machine. I'm not sure that you're going to get a
useful result out of C-Reduce here, if you don't do that.
John
On 8/6/20 2:01 PM, Jack wrote:
> Hello all,
>
> I've been using creduce to help track down a stack-smashing bug in gcc
> when it compiles a particular file in the boost library. I'm reducing
> the boost file, and the interestingness test just checks for "stack
> smashing" in the gcc output. One problem is that the bug is not fully
> repeatable - sometimes only happening about 40% of the time. My
> understanding is that this may cause creduce to reject some true
> failures as uninteresting, but should still produce valid results. As
> far as I know, the test.sh does not produce any false positives, just
> some false negatives.
>
> As a result of Isaiah, I lost power recently (all OK now, I'm in
> southeast CT) and when I started up the system just now, the cpp file in
> the working directory does not fail at all (over 100 tests.) So, if I'm
> reducing test-file.cpp, what (if anything) can I assume about the
> version of test-file.cpp at any point during the run?. If it is not
> necessarily an "interesting" file, then I don't understand how creduce
> keeps track of where it is. If it should always be an "interesting"
> file, then what might have gone wrong for it to now NOT be interesting?
>
> The last few lines of the log file (captured by a "tee" command) are
> (90.8 %, 299086 bytes)
> (90.8 %, 299079 bytes)
> (90.8 %, 299056 bytes)
> ===< pass_clex :: rm-toks-4 >===
> (90.8 %, 299028 bytes)
> (90.9 %, 299002 bytes)
> (90.9 %, 298990 bytes)
> and the remining test cpp file is 298990 bytes long.
>
> Thanks for any suggestions or pointers, even if just to the "fine
> manual" I need to read.
>
> For now, I suppose I'll just have to start over, losing close to 80
> hours of work.
>
> Separate suggestion: have creduce save some marker of its current state,
> so it can pick up where it left off, in case of a power failure or some
> other interruption.
>
> Jack