[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[creduce-dev] question on creduce usage
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