mirror of https://github.com/GreptimeTeam/greptimedb.git synced 2026-10-03 02:25:35 +00:00

Files

T

Ning Sun edc81c2355 ci: update cargo fuzz command to use nightly toolchain explicitly (#9298 )

* ci: update cargo fuzz command to use nightly toolchain explicitly

* ci: honor RUSTUP_TOOLCHAIN pin in fuzz orchestration script

An explicit `+toolchain` argument overrides the RUSTUP_TOOLCHAIN env var
in rustup precedence, so the hard-coded `cargo +nightly` in
run-fuzz-targets.sh bypassed the pinned FUZZ_RUST_TOOLCHAIN
(nightly-2026-03-21) configured in the workflow.

- Invoke `cargo +"${RUSTUP_TOOLCHAIN:-nightly}" fuzz run` in the script
  so CI uses the pinned toolchain and local runs fall back to the
  floating nightly
- Pass RUSTUP_TOOLCHAIN through to all four fuzz-test action invocations,
  covering the no-prebuilt-binaries path and making the reproduce command
  in the summary print the exact pinned toolchain
- Add test_rustup_toolchain_env_is_honored covering the pinned-env
  scenario for both the cargo invocation args and the summary text

Addresses #9298 (review).

Signed-off-by: Ning Sun <sunning@greptime.com>

---------

Signed-off-by: Ning Sun <sunning@greptime.com>

2026-09-23 01:41:27 +00:00

2.7 KiB

Raw Blame History

Fuzz Test for GreptimeDB

Setup

Install the fuzz cli first.

cargo install cargo-fuzz

Note: cargo-fuzz instruments targets with -Zsanitizer=fuzzer, so fuzz targets must be built with a nightly toolchain (the workspace default toolchain does not need to be nightly — make fuzz / make fuzz-ls invoke cargo +nightly for you; CI pins its own nightly in FUZZ_RUST_TOOLCHAIN).

Start GreptimeDB
Copy the .env.example, which is at project root, to .env and change the values on need.

For stable fuzz tests

Set the GreptimeDB MySQL address.

GT_MYSQL_ADDR = localhost:4002

For unstable fuzz tests

Set the binary path of the GreptimeDB:

GT_FUZZ_BINARY_PATH = /path/to/

Change the instance root directory(the default value: /tmp/unstable_greptime/)

GT_FUZZ_INSTANCE_ROOT_DIR = /path/to/

Run

List all fuzz targets

cargo fuzz list --fuzz-dir tests-fuzz

Run a fuzz target.

cargo fuzz run fuzz_create_table --fuzz-dir tests-fuzz -D -s none

Crash Reproduction

If you want to reproduce a crash, you first need to obtain the Base64 encoded code, which usually appears at the end of a crash report, and store it in a file.

Alternatively, if you already have the crash file, you can skip this step.

echo "Base64" > .crash

Print the std::fmt::Debug output for an input.

cargo fuzz fmt fuzz_target .crash --fuzz-dir tests-fuzz -D -s none

Rerun the fuzz test with the input. You can override fuzz input with environment variables. For example, to override fuzz input like:

FuzzInput {
    seed: 6666,
    actions: 175
}

you can run with GT_FUZZ_OVERRIDE_SEED=6666 and GT_FUZZ_OVERRIDE_ACTIONS=175:

GT_FUZZ_OVERRIDE_SEED=6666 GT_FUZZ_OVERRIDE_ACTIONS=175 cargo fuzz run fuzz_target .crash --fuzz-dir tests-fuzz -D -s none

For more details, visit cargo fuzz or run the command cargo fuzz --help.

Repartition Metric Dump Artifacts

For fuzz_repartition_metric_table, dump artifacts are written under one run directory.

Table data snapshots: <logical_table>.table-data.csv
SQL traces per logical table: <logical_table>.trace.sql
Seed metadata: seed.meta

SQL trace behavior:

Insert SQL is appended after successful execution with comment fields including started_at_ms and elapsed_ms.
Repartition events are broadcast to all logical table trace files with comment fields including action_idx, started_at_ms, elapsed_ms, and SQL text.

Run directory lifecycle:

On success, the run directory is cleaned up.
On failure, the run directory is retained for CI/local diffing.

2.7 KiB Raw Blame History