crashpad-rs
Rust bindings for Google Crashpad crash reporting system.
Project Structure
Directory | Package Name | Description |
---|---|---|
crashpad-sys/ |
crashpad-rs-sys |
Low-level FFI bindings to Crashpad C++ library |
crashpad/ |
crashpad-rs |
Safe Rust wrapper API |
Note: The directories are published with different names to avoid conflicts on crates.io:
crashpad-sys/
→crashpad-rs-sys
crashpad/
→crashpad-rs
Features
- Cross-platform: macOS, Linux, iOS, Android, Windows
- Safe API: Rust-safe wrapper around Crashpad C++ library
- Flexible Configuration: Runtime handler configuration
- Native Crash Handler Included: Handler executable built-in
- Multiple Build Strategies: Choose between source build or pre-compiled binaries
- Automatic Handler Distribution: Optional bundler for seamless deployment
Installation
Add to your Cargo.toml
:
[]
# x-release-please-start-version
= "0.2.7"
# x-release-please-end-version
# Optional: For automatic handler bundling at build time
[]
# x-release-please-start-version
= "0.2.7"
# x-release-please-end-version
Build Strategies
The crashpad-rs-sys
crate supports three mutually exclusive build strategies:
Strategy | Description | Platform Support | Requirements |
---|---|---|---|
vendored (default) |
Builds from submodules with pinned versions | Linux, macOS, iOS, Android (❌ Windows) | Git submodules |
vendored-depot |
Builds using Google's depot_tools with latest sources | All platforms (✅ Windows tested) | Python 3.8+, depot_tools |
prebuilt |
Uses pre-compiled binaries from GitHub Releases | Linux (x86_64, aarch64), macOS (x86_64, aarch64), Windows (x86_64) | Network access |
⚠️ Important: Only one strategy can be enabled at a time. These features are mutually exclusive.
Choose a strategy by enabling the corresponding feature:
# Use pre-compiled binaries (fastest build)
= { = "0.2.6", = ["prebuilt"] }
# Use depot_tools for Windows builds
= { = "0.2.6", = ["vendored-depot"] }
# Default: vendored (builds from submodules)
= "0.2.6"
Note:
vendored
is the default and recommended for most platforms except Windowsvendored-depot
is required for Windows native buildsprebuilt
provides fastest builds but requires pre-built archives for your platform
Handler Bundling (Optional)
If using the bundler, create a build.rs
:
Quick Start
use ;
use HashMap;
Configuration
Basic Configuration (Local Only)
// Minimal config - crashes saved locally, no upload
let config = builder
.handler_path // Required on desktop platforms
.database_path // Where to store crash dumps
.build;
Production Configuration
// Full configuration with upload server
let config = builder
.handler_path
.database_path
.metrics_path // Optional: metrics storage
.url
.build;
Platform-Specific Configuration
Desktop (macOS/Linux/Windows)
// Handler path is required for desktop platforms
let config = builder
.handler_path // Must point to handler executable
.database_path
.build;
iOS/tvOS/watchOS
// iOS uses in-process handler - no handler_path needed
let config = builder
.database_path // Relative to app's Documents directory
.url
.build;
Android
// Android can use external handler (as .so file in APK)
let config = builder
.handler_path // Renamed for APK distribution
.database_path
.build;
Environment-Based Configuration
// Adjust configuration based on environment
let config = if cfg! else ;
Handler Arguments Configuration
// Control handler behavior with high-level API
let config = builder
.database_path
.rate_limit // Disable upload rate limiting
.upload_gzip // Disable gzip compression
.periodic_tasks // Disable periodic maintenance
.identify_client_via_url // Don't add client ID to URL
.build;
// Advanced: use low-level API for custom arguments
let config = builder
.database_path
.handler_argument // Enable self-monitoring
.handler_argument
.build;
// Mix high-level and low-level APIs
let config = builder
.database_path
.rate_limit // High-level API
.handler_argument // Low-level API
.build;
Note: Handler arguments are currently ignored on iOS/tvOS/watchOS as they use an in-process handler with hardcoded settings. This may change in future Crashpad versions.
Platform Support
Platform | Architecture | Status | Handler Type |
---|---|---|---|
macOS | x86_64, aarch64 | ✅ Stable | External executable |
Linux | x86_64, aarch64 | ✅ Stable | External executable |
iOS | arm64, x86_64 sim | ✅ Stable | In-process |
Android | arm, arm64, x86, x86_64 | ✅ Stable | External/In-process |
Windows | x86_64 | ✅ Stable | External executable |
Advanced Features
Capturing Dumps Without Crashing
The dump_without_crash()
method allows you to capture diagnostic information without terminating your application. This is useful for:
- Debugging production issues
- Capturing state during recoverable errors
- Performance monitoring
- User-requested diagnostics
use ;
// Initialize Crashpad as usual
let client = new?;
let config = builder
.handler_path
.database_path
.build;
client.start_with_config?;
// Capture diagnostic dump on error condition
if let Err = some_operation
Examples
Running the Test Example
The test example automatically searches for the handler in common locations.
# Build and run directly
# The example will search for handler in:
# - target/debug/crashpad_handler (automatically found)
# - CRASHPAD_HANDLER environment variable (if set)
# - Current directory
- Test the available commands
# Show help # Capture a diagnostic dump without crashing # Trigger a real crash for testing # Run automated tests
Handler Deployment
The crashpad_handler
executable must be available at runtime. There are two approaches:
Automatic (Recommended)
Use crashpad-handler-bundler
to automatically copy the handler at build time:
1. Add to your Cargo.toml
:
[]
= "x.y.z"
[]
= "x.y.z"
2. Create build.rs
in your project root:
3. Use in your application:
use ;
4. Build and run:
# Output: cargo:warning=crashpad_handler copied to /path/to/target/debug/crashpad_handler
# Handler is automatically available
The bundler handles:
- Finding the built handler from crashpad-rs-sys
- Copying to the correct target directory
- Setting executable permissions on Unix
- Platform-specific naming (
.exe
on Windows,.so
on Android)
Manual Deployment
If not using the bundler, you need to manually deploy the handler:
-
Same directory as application (simplest)
my-app/ ├── my-app └── crashpad_handler
-
System path (for installed applications)
/usr/local/bin/crashpad_handler
-
Environment variable (flexible deployment)
-
Bundled in package (platform-specific)
- macOS: Inside .app bundle
- Linux: In AppImage or snap
- Android: As .so file in APK (renamed to
libcrashpad_handler.so
) - iOS: Not needed (in-process)
Documentation
For Library Users
- API Documentation - Full API reference
- Integration Guide - Production integration
For Contributors
- Development Guide - Build, test, and contribute
- Architecture - Technical design decisions
- Conventions - Coding standards
Known Limitations
- iOS Handler Arguments: Handler arguments are ignored on iOS/tvOS/watchOS as the in-process handler uses hardcoded settings (Crashpad limitation, see bug #23)
- Handler Update: No automatic update mechanism for deployed handlers
- Windows vendored build: The default
vendored
strategy doesn't support Windows; usevendored-depot
orprebuilt
instead
Contributions are welcome!
Troubleshooting
Handler Not Found
- Verify handler executable exists and has execute permissions
- Check
CRASHPAD_HANDLER
environment variable - Explicitly set path in config:
.handler_path("/path/to/crashpad_handler")
- Ensure handler architecture matches application
Crashes Not Being Captured
- Confirm handler process is running
- Check database path has write permissions
- Verify network connectivity for uploads
License
Licensed under MIT license (LICENSE).
Contributing
Contributions are welcome! See DEVELOPING.md for build and test instructions.
Support
- Issues: GitHub Issues
- Discussions: GitHub Discussions