A segmentation fault (core dumped) in Python when calling a function that interacts with a Rust library (like etebase-rs via etebase-py) typically indicates a memory access violation in the Rust code. This could be due to issues like:

• Memory corruption (e.g., dereferencing null/invalid pointers, buffer overflows).
• Thread safety issues (e.g., data races, improper synchronization).
• FFI (Foreign Function Interface) mismatches (e.g., incorrect data types, ownership issues).
• Uninitialized or freed memory access.

How to Investigate

1. Check the Backtrace

Run the Python script with gdb to capture the backtrace when the segfault occurs:

gdb --args python3 your_script.py

In gdb, run:

run
bt full  # Print full backtrace when it crashes

This will show where the crash happens (C/Rust stack frames).

2. Enable Rust Debug Symbols

Ensure your etebase-rs library is built with debug symbols:

# In Cargo.toml for etebase-rs
[profile.release]
debug = true

Rebuild and reinstall the library, then retry.

3. Isolate the Issue

• Test subscribe_changes in Rust directly: Write a minimal Rust test to call subscribe_changes without Python. If it crashes, the issue is in Rust.
• Test with a minimal Python script: Strip down your Python code to the bare minimum (just Client initialization + subscribe_changes). If it works, the issue might be in your Python code or how you’re using the library.

4. Review FFI Bindings

If etebase-py uses pyo3 or cbindgen to expose Rust to Python:

• Verify that all types passed between Python and Rust are compatible (e.g., no mismatched pointers or lifetimes).
• Check for proper error handling in the FFI layer (e.g., Rust panics should not propagate to Python as segfaults).

5. Check for Known Issues

• Look at the etebase-rs and etebase-py GitHub issues for similar reports.
• If you’re using a custom build, ensure all dependencies (e.g., libetebase) are up-to-date and compatible.

6. Valgrind or AddressSanitizer

Run your Python script under valgrind to detect memory issues:

valgrind --leak-check=full python3 your_script.py

Or, for Rust, compile with AddressSanitizer:

# In Cargo.toml
[profile.release]
sanitizer = "address"

Then run your tests.

7. Threading Issues

If subscribe_changes spawns threads or uses async code:

• Ensure thread safety (e.g., no shared mutable state without synchronization).
• Check for proper Send/Sync trait implementations in Rust.

8. Core Dump Analysis

If you have a core dump file (core):

gdb python3 core
bt full

This can pinpoint the exact line in Rust or C code causing the crash.

Common Pitfalls

• Dangling pointers: Rust code might be freeing memory that Python still holds.
• Incorrect lifetimes: FFI functions might return references to data that doesn’t live long enough.
• Mismatched types: Python and Rust might disagree on the layout of a struct or enum.

Next Steps

1. Share the backtrace from gdb or valgrind for more targeted help.
2. Minimal reproducible example: Provide the smallest code snippet (Rust + Python) that triggers the crash.
3. Check Rust logs: If etebase-rs uses log or tracing, enable debug logging to see if it reveals anything before the crash.

Question: Have you tried running the Rust code directly (without Python) to see if the issue persists? If so, what happened?