deadlock found about chromiumoxide HOT 8 CLOSED

Each sevice instance create 8 chromium instances, each request to my service would generate HTML to be render, with debug=true in query string, generated HTML would be respond, without this flag, my service would random choose an chromium instance and set content for it.

Sorry I'm afraid I did not understand that part. So I have a couple of questions myself:

• you're launching 8 different instances of chromium? Each with a new remote-debug-port?
• you're connecting chromiumoxide::Browser to each of them separately?
• with debug=true you mean the rust profile right?

If so, then I might know what happens here. There is a difference in overflow handling between rust's release and debug mode: http://huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/
basically in release mode there aren't any overflows.
So there seems to be a code path that loops forever, from gdb output, this is the suspect: https://github.com/mattsse/chromiumoxide/blob/main/src/handler/target.rs#L273-L490

Maybe this here: https://github.com/mattsse/chromiumoxide/blob/main/src/cmd.rs#L145 ?

So my hunch is, when you run a lot of commands that may fail, perhaps they don't time out or aren't cleared, so maybe there is some weird edge case that causes so much back pressure to the CommandList that target::poll loops for ever?
Just a hunch.
Those sections could definitely use some log statements. I'd start there.

from chromiumoxide.

I fixed a bug that was related to Commandchain::poll in #56 that resulted in timed out requests weren't cleared and Commandchain::poll called continuously.
Maybe this fixes this issue as well

from chromiumoxide.

I'm trying to fix this issue, but I am not familiar enough with this part of the code for now, if you can help me with this issue, that would be the best.

from chromiumoxide.

you're launching 8 different instances of chromium? Each with a new remote-debug-port?

Yes, I launch chromium via --remote-debugging-port=0

you're connecting chromiumoxide::Browser to each of them separately?

Yes, and actix_web::spawn a task to consume everything from Handler.

with debug=true you mean the rust profile right?

No, it's some logic in my service, I was just trying to explain, it's not hang in my code, but, my poor English make you confused.

When I found service is hang, I stopped requests to this instance, and wait for 10 hours, still hang there, and the output of GDB is similar. So, I do belive that not about back pressure.

Here is my htop output, I hope this would be helpful.

from chromiumoxide.

I've killed all chromiumoxide process, and nothing changed, hang without any error.

from chromiumoxide.

Good to know, I would like to ask my QA partner test again.

from chromiumoxide.

Hi, after so many days, finally I found the root cause.

In my case, my service would create and drop Browser again and agin, and without waitpid, there would be a lot of zombie process.

Those zombie process took all available pid, and we could never create new Browser, service looks like hang.

Sorry for my noise, and thanks for your great work.

from chromiumoxide.

This how I fix my problem:

  #[cfg(target_family = "unix")]
  unsafe {
      nix::sys::signal::signal(
          nix::sys::signal::Signal::SIGCHLD,
          nix::sys::signal::SigHandler::SigIgn,
      )
      .expect("set SIGCHLD to SIG_IGN");
  }

from chromiumoxide.