[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [creduce-dev] question on creduce usage
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.
On 8/6/20 2:01 PM, Jack wrote:
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