Unwind triggered while reading from TcpStream. #6979
Comments
fooooter
added
A-tokio
|
Not much comes to mind for me. Are you able to create a small program that reproduce this? |
|
Alternatively, try running the program under gdb to get a better stack trace. |
use tokio::io::{AsyncBufReadExt, BufReader};
use tokio::net::TcpListener;
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
let listener = TcpListener::bind("127.0.0.1:8080").await?;
loop {
let (stream, _) = listener.accept().await?;
tokio::spawn(async move {
let mut reader = BufReader::new(stream);
let mut buf = String::new();
loop {
match reader.read_line(&mut buf).await {
Ok(l) => {
if l == 0 {
return;
}
},
Err(_) => {
return;
}
};
}
});
}
}Is this enough, or do I need to create a separate repository for this, or do something else? |
|
If there was no output, how do you know it unwound? |
|
I used |
|
I tried running your code and connecting with telnet; I was unable to observe any issues. Please provide more information on what actually goes wrong. |
|
It fails during regular HTTP requests. To reproduce this bug, a regular browser should suffice (tried Firefox and Chromium, as I said earlier). Alright, I tried using GDB, and here's what happened AFTER But ends up there: Here's a backtrace of a moment right before it starts hanging forever: Hope it suffices. I'm kind of worried, that I have my standard library corrupted or something, because of those "No such file or directory" warnings. |
|
That's not unwinding (i.e. there's no panic). You hit a What happens is that first the browser sent a bunch of lines describing the web page it wants to open. Then, it waits for a reply. However, now both your program and the browser is waiting for more data forever, so the result is that both sleep forever, because they're waiting for each other. |
|
I understand, but now this begs the question whether all |
|
HTTP requests do not signal the end of the request with EOF because they might want to send another request afterwards. Instead, that is done by sending an empty line after the last header. Once you get an empty line, you should send the reply |
|
What about the request body then which is after a blank line? |
|
Your code needs to parse the HTTP response to understand how the body is framed. |
|
Yeah, basically the http headers explain how to read the body. There are several different ways you might need to do it, and servers must support them all to be complete. |
|
Yeah, I'll probably need to get the value of |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version
Platform
Linux area51 6.6.58-gentoo-r1 #1 SMP PREEMPT_DYNAMIC Tue Nov 5 19:10:09 CET 2024 x86_64 Intel(R) Core(TM) i5-9300H CPU @ 2.40GHz GenuineIntel GNU/LinuxDescription
I'm currently writing a PoC HTTP web server (a working example) and I've stumbled across an issue, where an unwind is generated while reading a request from a client (I used Firefox and Chromium) using BufReader (right before reading a request body, to be exact). I've tested several different methods, like
read_to_string,read_lineorread_to_end, but the outcome was still the same. Unfortunately, I cannot provide any backtrace, as it's a "weird" kind of unwind without any output whatsoever, even though I haveRUST_BACKTRACEset tofull. As I've tested this mostly withread_line, I found out, that the condition for this to occur is when a line being read consists only of\r\n. Might be a similar case to #2532.I tried this code:
This code is partially working (cannot read POST request body, but the rest is properly appended into
requeststring):The text was updated successfully, but these errors were encountered: