<feed xmlns='http://www.w3.org/2005/Atom'>
<title>typhoon.git/src/fuzz_test.sh, branch master</title>
<subtitle>The typhoon chess playing engine.
</subtitle>
<id>https://git.acknak.org/cgit/typhoon.git/atom?h=master</id>
<link rel='self' href='https://git.acknak.org/cgit/typhoon.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.acknak.org/cgit/typhoon.git/'/>
<updated>2026-09-19T01:26:28Z</updated>
<entry>
<title>fuzz_test.sh: copy the binary to a private path before looping</title>
<updated>2026-09-19T01:26:28Z</updated>
<author>
<name>Scott Gasch</name>
<email>scott@gasch.org</email>
</author>
<published>2026-09-19T01:26:28Z</published>
<link rel='alternate' type='text/html' href='https://git.acknak.org/cgit/typhoon.git/commit/?id=187e321c450740dc0fba2c1d29917851d45a822f'/>
<id>urn:sha1:187e321c450740dc0fba2c1d29917851d45a822f</id>
<content type='text'>
A concurrent gmake clean (update_head_reference.sh, precommit_check.sh)
unlinks ./_typhoon out from under a fuzz loop mid-run, breaking every
subsequent iteration with "not found/executable". Observed live running
this alongside update_head_reference.sh today. Copy once up front instead
of exec'ing $BIN in place, so later rebuilds in the working tree can't
touch what the loop is actually running.

Co-Authored-By: Claude Sonnet 5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>Add fuzz_test.sh: a long-running gdb-driven fuzz loop over cross_sectional_200k.ep_</title>
<updated>2026-09-19T01:17:39Z</updated>
<author>
<name>Scott Gasch</name>
<email>scott@gasch.org</email>
</author>
<published>2026-09-19T01:17:39Z</published>
<link rel='alternate' type='text/html' href='https://git.acknak.org/cgit/typhoon.git/commit/?id=284113f878444ded9cd36b4a70900efd036651de'/>
<id>urn:sha1:284113f878444ded9cd36b4a70900efd036651de</id>
<content type='text'>
Documents two build/invocation bugs hit getting this working: DEBUG builds
need MP=1 too or --cpus is silently unrecognized, and gdb's
"handle SIGTRAP nostop noprint pass" breaks thread control against the
MP/pthread binary (misdiagnosed at first as a sandboxed ptrace restriction,
but reproduces outside any harness and goes away once that directive is
dropped).

Co-Authored-By: Claude Sonnet 5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
</feed>
