cargo-udeps requires a nightly toolchain and its pinned version (0.1.61) no longer detects unused dependencies against current cargo internals — unused deps have landed on main undetected (e.g. humantime in common-frontend since #6689). cargo-shear is a standalone static analyzer that runs on any toolchain. - Swap 'make check-udeps' / 'make fix-udeps' recipes to 'cargo shear' / 'cargo shear --fix' and retire scripts/fix-udeps.py - CI: install cargo-shear in the check-udeps job; drop the build cache and protoc steps (cargo-shear never compiles) - Remove ~150 unused dependency declarations found by cargo-shear, move misplaced deps to the correct sections, drop orphaned [workspace.dependencies] entries (arrow-cast, rustc-hash) - Add [package.metadata.cargo-shear] ignored entries with explanations for dependencies that are structurally required despite no textual reference: sqlparser (required by sqlparser_derive expansions in datatypes, common-query), common-error (required by common-macro's stack_trace_debug expansions in session, tests-fuzz), k8s-openapi (feature-pinning for the transitive kube dependency in tests-fuzz), tikv-jemalloc-sys (link-only, enables jemalloc profiling features in common-mem-prof), protobuf (required by build.rs-generated bindings in log-store) - Drop the obsolete [package.metadata.cargo-udeps.ignore] sections Part of #9289 Signed-off-by: Ning Sun <sunning@greptime.com>
Fuzz Test for GreptimeDB
Setup
- Install the fuzz cli first.
cargo install cargo-fuzz
- Start GreptimeDB
- Copy the
.env.example, which is at project root, to.envand 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_msandelapsed_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.