[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