Stream: rust-toolchain

Topic: ✔ debugging temporaries

Yoshua Wuyts (Feb 29 2024 at 00:51):

I'm too sleepy to file a proper bug report; but I just spent a good 30 mins debugging an issue that turned out to be related to temporaries: https://gist.github.com/yoshuawuyts/88bb552bb08ad5c1d53216c97fcc0f6e

Yoshua Wuyts (Feb 29 2024 at 00:53):

These are all calls on the IncomingResponse type - .consume().unwrap() to get to the incoming body. Then .stream().unwrap() to get to the actual byte stream. But if you don't assign them to a local variable, it apparently does an early drop which triggers a panic.

Yoshua Wuyts (Feb 29 2024 at 00:54):

I'm not even sure this is a bug, and suspect it might just be an interaction between WIT's expressiveness limitations + our current limited stack trace / debugging facilities?

Yoshua Wuyts (Feb 29 2024 at 00:54):

Not sure what to do with this; but I figured it'd be worth sharing at a minimum

Yoshua Wuyts (Feb 29 2024 at 00:54):

If this tripped me up, it'll probably trip others up

Alex Crichton (Feb 29 2024 at 01:04):

While I can't say for certain this looks like you may be running into this behavior, which means you're right that WIT can't express the parent/child relationship here so the bindings can't do much better (at least not the auto-generated bindings)

Yoshua Wuyts (Feb 29 2024 at 01:05):

ohhhh right

Yoshua Wuyts (Feb 29 2024 at 01:05):

sorry, you linked to that earlier

Yoshua Wuyts (Feb 29 2024 at 01:05):

and I didn't read the link - that's on me

Yoshua Wuyts (Feb 29 2024 at 01:05):

I kind of forgot :sweat_smile:

Yoshua Wuyts (Feb 29 2024 at 01:05):

yeah this looks like what I'm running into I think

Yoshua Wuyts (Feb 29 2024 at 01:05):

haaaa

Yoshua Wuyts (Feb 29 2024 at 01:06):

okay yeah that completely explains it

Yoshua Wuyts (Feb 29 2024 at 01:07):

I think I'm so used to just relying on the Rust type system, that this kind of runtime dependency just really threw me

Notification Bot (Feb 29 2024 at 01:09):

Yoshua Wuyts has marked this topic as resolved.

Yoshua Wuyts (Feb 29 2024 at 01:10):

(I suspect this will resolve the issue; proactively closing it)

Yoshua Wuyts (Feb 29 2024 at 01:13):

Ah yeah, that did do the trick!

Yoshua Wuyts (Feb 29 2024 at 01:13):

It does lead to some fun cases like this tho:

/// An HTTP response
#[derive(Debug)]
pub struct Response {
    bytes_read: u64,
    content_length: u64,
    headers: Vec<(String, Vec<u8>)>,
    reactor: Reactor,

    // IMPORTANT: the order of these fields here matters. `incoming_body` must
    // be dropped before `body_stream`.
    body_stream: InputStream,
    incoming_body: IncomingBody,
}

Alex Crichton (Feb 29 2024 at 01:15):

heh good point! One thing you can do is to use ManuallyDrop with a Drop impl to explicitly write out the order of the drops (not that the struct field ordering doesn't work though)

Yoshua Wuyts (Feb 29 2024 at 01:15):

oh yeah, good call

Yoshua Wuyts (Feb 29 2024 at 01:16):

I don't know how yet; but we'll likely want to issue some guidance around this at some point

Yoshua Wuyts (Feb 29 2024 at 01:16):

it sounds like this might be part of the current streaming model, and at least having a canonical one-pager to point at and say: "you're running into this case, do this thing" could be good

Yoshua Wuyts (Feb 29 2024 at 01:17):

(I might volunteer doing that if we have a place to put it)

Alex Crichton (Feb 29 2024 at 01:18):

agreed would be good to have :+1:

Last updated: Nov 22 2024 at 17:03 UTC