Assert in libuv #110
Comments
|
It looks like the handle for the pipe is gone for some reasons. By looking at the code of Could it happen that you close the handle for some reasons (as an example, in case of errors) and then you try to reuse it when you should create a new one from scratch instead? |
|
Actually I'm doing this: pipe = uvw::Loop::getDefault()->resource<uvw::PipeHandle>();
process_exe->stdio(static_cast<uvw::FileHandle>(0), uvw::ProcessHandle::StdIO::IGNORE_STREAM);
uv_stdio_flags f = (uv_stdio_flags)(UV_CREATE_PIPE | UV_READABLE_PIPE);
uvw::Flags<uvw::ProcessHandle::StdIO> ff(f);
process_exe->stdio(*pipe, ff);
//When pipe is closed, remove it and close it
pipe->once<uvw::EndEvent>([](const uvw::EndEvent &, auto &cl) { cl.close(); });
pipe->on<uvw::DataEvent>([this](uvw::DataEvent &ev, auto &)
{
[...]
});
Utils::CStrArray arr(cmd);
process_exe->spawn(arr.at(0), arr.data());
pipe->read();The only place where I'm closing the handle is for the |
|
You should stop or close a handle in case of errors during a read too.
Unfortunately the pipe shares part of its API with the stream and the documentation isn't that easy to follow. It could happen that you're getting an error on your handle for unknown reasons (try to analyze the error code for that) and you don't close it. After all, you are experiencing the problem during a read on an invalid descriptor. |
|
Actually, from here I see that your are ignoring errors on the pipe handle. |
|
I'm marking the issue as invalid for it doesn't look like it's due to a bug in |
|
Thanks for all your pointers. I tried to listen to ErrorEvent for the pipe, it did not trigger before asserting. |
|
Interesting. Neither the |
|
No, neither I did some more test and found out that is failing due to I close this bug, as it's not relevant. |
|
@raoulh Any suggestion to change the API and make it more usable is welcome. |
|
It would have been better to be able to do something like: exe = uvw::Loop::getDefault()->resource<uvw::ProcessHandle>();
exe->once<uvw::ErrorEvent>([this](const uvw::ErrorEvent &ev, auto &)
{
process_exe->close();
});
[...] //setup pipe
if (!exe->spawn())
{
//early failure, ErrorEvent is not called
std::cout << "fail to start process: " << exe->errorMsg() << std::endl;
exe->close();
}
else
{
pipe->read();
}But I don't know if it's a good idea to differenciate between error types. It makes sense when like in this example the |
|
I also found why I was leaking fds... I did not close() the handle somewhere in case of ErrorEvent... That was not clear until you explained it here. |
|
You are welcome. You know, you're skilled and when you pop up with an issue it's usually an interesting problem from which I can learn something. ;-)
I suggest to not remove the What about? |
|
Glad to help :) That's also why I posted here in the first place. About the return value and the |
|
As a side note, did you see the |
|
Yes I know that libuv/uvw does not do any close itself. I was talking about my usage example above. The |
|
Oho, I got it now. Sorry. Yeah, right, it's better not to call |
|
I just checked the libuv code, it would |
Hi,
I have a strange bug, and don't know if it's in uvw, libuv or my own code. I will explain here and maybe someone has any hints.
I have an Idle handle that start a process at some point. It works and at some random point in time my my code crashes with an assert exactly when the process is launched:
What my code does is basically easy:
Full code of the function is here:
https://github.com/calaos/calaos_base/blob/master/src/bin/calaos_server/IO/ExternProc.cpp#L147
It works. Sometime it works for a long time (hours). And then it crashes with this backtrace:
When inspecting the
stream->io_watcher.fdit is -1. So the assert is correct that the uv_read cannot start- But why is this sometime -1... I really don't know...My question here is: do I need to setup something or check something prior starting
pipe->read()? Is it a bug in libuv? uvw?Thank you very much for any pointer.
The text was updated successfully, but these errors were encountered: