Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

seg faults when working with composite types #411

Open
darrenmothersele opened this issue May 24, 2024 · 3 comments
Open

seg faults when working with composite types #411

darrenmothersele opened this issue May 24, 2024 · 3 comments

Comments

@darrenmothersele
Copy link

Hi,

I am getting seg faults from plrust code when working with composite types. I've seen this when working locally (in Docker), using cloudnative-pg, and in RDS on AWS (so I'm pretty sure it's not an environment issue).

I have a few cases where this occurs and I have not been able to track down what is causing it. I think it might be related to PgHeapTuple<AllocatedByRust>. I have seen it when calling the functions directly, but it usually occurs when calling a plrust function from a plpgsql function. Here's a minimal example that triggers it...

DROP TYPE IF EXISTS testevent CASCADE;
create type testevent AS
(
    entity_id text
);

DROP FUNCTION IF EXISTS test_fault_inner;
CREATE OR REPLACE FUNCTION test_fault_inner(entity_id text)
    RETURNS testevent
    LANGUAGE plrust AS
$_$
    let entity_id = entity_id.unwrap();

    let mut e = PgHeapTuple::new_composite_type("testevent")?;
    Spi::connect(|mut client| {
        e.set_by_name("entity_id", entity_id)?;
        Ok(Some(e))
    })
$_$;


DROP FUNCTION IF EXISTS test_fault;
CREATE OR REPLACE FUNCTION test_fault(id text)
    RETURNS void
    LANGUAGE plpgsql AS
$_$
DECLARE
    temp testevent;
BEGIN
    temp = test_fault_inner(id);
    RAISE LOG '%', temp.entity_id;
end
$_$;

SELECT test_fault(gen_random_uuid()::text);
SELECT test_fault(gen_random_uuid()::text);

Hopefully I'm holding it wrong.

@workingjubilee
Copy link
Contributor

@darrenmothersele It should not be possible for you to "hold it wrong" and get a segfault. Doing so means a bug in our code or a bug in Postgres.

I am unfortunately aware of what bug you probably have hit.

Do you have any reproducers that do not use SPI in the Rust function?

There is a known soundness problem with SPI in pgrx, which PL/Rust depends on. It has to do with entering SPI, which creates a new memory context, and everything created in that memory context needs to be appropriately bounded by that context. I have been hammering away at new API which can represent memory contexts and their lifetimes but there are a few more steps until I can land the fixes in PL/Rust.

That said if you have a reproducer that does not require such, then I am very interested, as that's a new bug.

@darrenmothersele
Copy link
Author

Hi, just wanted to confirm that I think our issues were related to the SPI soundness problem.

Thanks

@workingjubilee
Copy link
Contributor

Cool! Good to know. pgrx 0.12 doesn't address that, unfortunately, but did lay all the preliminary groundwork for such.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants