-
-
Notifications
You must be signed in to change notification settings - Fork 274
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
Stack overflow in pulls(...).get(...) #136
Comments
The same issue in let pr = octocrab.pulls(owner, repo).get(1).await?;
println!("{}", pr.title); Result: thread 'main' has overflowed its stack
error: process didn't exit successfully: `target\debug\test.exe` (exit code: 0xc00000fd, STATUS_STACK_OVERFLOW) |
I can look at this over the weekend. Something is using a lot of stack space when deserializing. I came across a similar issue when writing the deserializer for events. It only seems to really be a problem when run in debug, it gets optimized away in release. At least in the cases I found. |
This one has been on my mind for a while, as it's come up in other things also. So going to put all the info I uncovered here. Here is a minimum program to reproduce: #[tokio::main(worker_threads = 1)]
async fn main() -> octocrab::Result<()> {
let x = octocrab::instance()
.pulls("XAMPPRocky", "octocrab")
.get(129u64)
.await?;
println!("{:#?}", x.id);
Ok(())
} Stack usage in debug (using https://github.com/d99kris/stackusage): $ stackusage target/debug/stackoverflow 1>/dev/null
stackusage log at 2021-11-12 19:55:06 ----------------------------------------
pid id tid requested actual maxuse max% dur funcP name
175997 0 175997 8388608 8384512 1889704 22 0 (nil) stackoverflow
175997 1 175998 2097152 2097152 68424 3 0 0x557526111b30 tokio-runtime-w
175997 2 175999 2097152 2097152 27016 1 0 0x557526111b30 tokio-runtime-w Max stack usage is 1889704 bytes, ~1.8MiB. But when built in release mode: $ stackusage target/release/stackoverflow 1>/dev/null
stackusage log at 2021-11-12 19:59:37 ----------------------------------------
pid id tid requested actual maxuse max% dur funcP name
176208 0 176208 8388608 8376320 600080 7 1 (nil) stackoverflow
176208 1 176209 2097152 2097152 24040 1 1 0x55b922b9b310 tokio-runtime-w
176208 2 176210 2097152 2097152 23160 1 1 0x55b922b9b310 tokio-runtime-w This drops to ~600KiB. We are only deserializing a
This output was from
And the overall stack usage in debug drops to ~1.1MiB:
If we also
There are a few more fields which look useful to box,
Usage drops to 548KiB. The usage in release mode drops to 182KiB:
The size of
I don't really get how There are likely other structs which have the same issue, but I can open a PR with these fields boxed to fix this one at least. I'll probably try dig deeper into the underlying cause too at some point. |
@wayofthepie Thank you for investigating! Yeah, I'm not sure why it's such a large amount in debug either. Maybe it's because in debug it's not removing all the stack frames from the nested calls and each of the fields in each stack frame is adding up to a lot. But that's just me guessing. Feel free to open a PR boxing those fields. |
How about releasing a new version for this fix? |
edit: I can reproduce this with older version as well now. I'm thoroughly confused and would appreciate any advice.
With current git, the following code results in
thread 'main' has overflowed its stack
.I have reduced this to
Deserializing a User is fine, it's just the User in the PullRequest (note the additional
{}
arounduser
) that reproduces the problem.edit: I now cannot repro this anymore with the snippet above, but rather this makes it crash now.
The text was updated successfully, but these errors were encountered: