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

Bug: memory leak after force unwind #53

Merged
merged 1 commit into from
May 1, 2016
Merged

Bug: memory leak after force unwind #53

merged 1 commit into from
May 1, 2016

Conversation

zonyitoo
Copy link
Owner

@zonyitoo zonyitoo commented May 1, 2016

This bug exists because in coroutine_entry, we cannot know whether the callback() is panicked. So we will continue the execution and set the state to State::Finished and yield back, which will cause memory leak, because the coroutine_exit is not called!!

@zonyitoo zonyitoo added the bug label May 1, 2016
@zonyitoo
Copy link
Owner Author

zonyitoo commented May 1, 2016

cc @lhecker Please review.

@zonyitoo
Copy link
Owner Author

zonyitoo commented May 1, 2016

Test snippet:

extern crate coio;

use coio::Scheduler;

fn main() {
    Scheduler::new()
        .run(|| {
            loop {
                let hdl = Scheduler::spawn(|| {
                    Scheduler::sched();

                    let _x = 1;
                    panic!("Just panic!");
                });

                assert!(hdl.join().is_err());
            }
        })
        .unwrap();
}

This process will not allocate memory continuously.

BTW: cc @lhecker , if you run this code with .with_worker(??), you will see a crash thread panicked while panicking. Stack trace shows that it crashes in Scheduler::park_processor's .unwrap(), which indicates that the self.idle_processor_mutex is poisoned. But

  • If you run the Scheduler with 1 thread, it won't crash at all.
  • If you remove the Scheduler::sched(), it won't crash at all.

I think it is because when the panic::catch_unwind is called, it will register to the current thread's local storage. So if you call Scheduler::sched(), this Coroutine may be stolen by the other thread .. so if this Coroutine panicked on the other Processor, it will still triggered the original thread's panic handler, which is the reason that it reports thread panicked while panicking.

These worth to open a new issue to solve this, and I have an idea. Nope. I don't have.

@lhecker lhecker merged commit 64e1334 into master May 1, 2016
@lhecker lhecker deleted the drop-memory-leak branch May 1, 2016 14:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants