Pyo3: Panic messages and other garbage data in docstrings

[ametisf]

EDIT: Now I went through the PyO3 github repo more and I found PR #1169 which does solve this issue for me. Sorry for issue noise, I'll leave it to you if you want to close this now or after it gets eventually merged. Thanks for all of your work!

I noticed this only when calling __mul__ from within __rmul__, the docstring for the __rmul__ methods was not set explicitly by me but instead it was what seems like random gibberish from the binary itself, the beginning might be some specific error message but quite possibly the whole stuff is just garbage memory.

My setup:
Linux 5.8.12_1 x86_64 (Void Linux)
Python 3.8.5
maturin in virtualenv with everything default
rustc 1.48.0-nightly (7f7a1cbfd 2020-09-27)
PyO3 version 0.12.1 in my project and tested with git master in the minimal example.

For this example on my machine the pyo3_bug.TestClass.__rmul__.__docstring__ string contained 'panic from Rust codepyo3_bug', in my own project (https://github.com/ametisf/sany-py) the .__rmul__.__docstring__ on two different classes looks like

'a Display implementation returned an error unexpectedly/home/adam/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/string.rsalready mutably borrowedassertion failed: step != 0/home/adam/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/iter/adapters/mod.rscalled `Option::unwrap()` on a `None` valuecalled `Result::unwrap()` on an `Err` valueCannot restore a PyErr while normalizing it/home/adam/.cargo/registry/src/github.com-1ecc6299db9ec823/pyo3-0.12.1/src/err/mod.rs/home/adam/.cargo/registry/src/github.com-1ecc6299db9ec823/pyo3-0.12.1/src/gil.rs/home/adam/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/str/pattern.rs/home/adam/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/iter.rssrc/buffer.rsBuffer index out of rangeinternal error: entered unreachable codesrc/ui/spectrogram.rssrc/ui.rssrc/wav/mod.rsHuman readable tag for the buffer.'

and

'a Display implementation returned an error unexpectedly/home/adam/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/string.rsalready mutably borrowed`,\n right: ``called `Option::unwrap()` on a `None` valuecalled `Result::unwrap()` on an `Err` valueCannot restore a PyErr while normalizing it/home/adam/.cargo/registry/src/github.com-1ecc6299db9ec823/pyo3-0.12.1/src/err/mod.rs/home/adam/.cargo/registry/src/github.com-1ecc6299db9ec823/pyo3-0.12.1/src/gil.rspanic from Rust code/home/adam/.cargo/registry/src/github.com-1ecc6299db9ec823/pyo3-0.12.1/src/pycell.rsBufferWaveTableCacheassertion failed: `(left == right)`\n  left: `Sampling rate must be grater than 0src/wav/mod.rsRIFF file type is not "WAVE"Only uncompressed PCM format (1) is supported, file specifies Only bit-dephts of 8, 16 and 24 are supported, file specifies WAVE file is missing "fmt " chunkMalformed "fmt " chunk (expected  bytes)WAVE file is missing "data" chunkBit-depths don\'t match fmt=__new__'

Minimal example:

Cargo.toml

[package]
name = "pyo3_bug"
version = "0.1.0"
authors = ["Frantisek Fladung <[email protected]>"]
edition = "2018"

[lib]
name = "pyo3_bug"
path = "src/lib.rs"
crate-type = ["cdylib"]

[dependencies]
pyo3 = { git = "https://github.com/PyO3/pyo3", features = ["extension-module"] }

src/lib.rs

use pyo3::prelude::*;
use pyo3::PyNumberProtocol;

#[pyclass]
#[derive(Clone)]
struct TestClass {
    data: u32,
}

#[pyproto]
impl pyo3::PyNumberProtocol for TestClass {
    fn __mul__(mut lhs: TestClass, rhs: u32) -> PyResult<TestClass> {
        lhs.data *= rhs;
        Ok(lhs)
    }

    fn __rmul__(&self, rhs: u32) -> PyResult<TestClass> {
        TestClass::__mul__(self.clone(), rhs)
    }
}


#[pymodule]
fn pyo3_bug(_py: Python, m: &PyModule) -> PyResult<()> {
    m.add_class::<TestClass>()?;
    Ok(())
}

[kngwyu]

Ah, sorry I noticed this bug but still have not merged the PR.

[davidhewitt]

@kngwyu anything I can do to help with getting #1169 merged? I think it would be nice to make a 0.12.2 release with a fix for this in it before we start merging the breaking changes for 0.13.

[kngwyu]

Thanks. I come back to OSS this week and will investigate it tomorrow.