Init failiure leads to seg fault #2129
Comments
When using a foreign libuv loop, context creation may fail after adding handles to the foreign loop... if so, it can no longer deal with the fatal error by unpicking the created context and returning NULL... it has to brazen it out with a half-baked context that has already started the destroy flow and allow the foreign loop to close out the handles the usual way for libuv. #2129
When using a foreign libuv loop, context creation may fail after adding handles to the foreign loop... if so, it can no longer deal with the fatal error by unpicking the created context and returning NULL... it has to brazen it out with a half-baked context that has already started the destroy flow and allow the foreign loop to close out the handles the usual way for libuv. #2129
|
Unfortunately, uniquely, libuv is "asymmetric" in its api... you can add handles to its loop without the loop running. But you cannot cleanly remove them from the loop without the loop running, since it stages handle close to complete only after having gone around its loop. And while not completed, libuv is containing dangling references to the related lws objects, which cannot be destroyed until all those libuv completions (needing a running loop) happened. For non-foreign loop, it doesn't matter since the loop is part of the context footprint and both can be destroyed. lws knows this for context destroy flow, it marks the context and wanting to be destroyed and returns to the libuv loop instead of destroying in one step, counts handles added by lws to the loop, counts their libuv handle close completions, and finalizes the lws destroy only when the count reaches 0 some time later. But this is a situation where we decide partway through we want to fatally fail creating the context and unpick the work returning NULL for the context... normally we can do that OK (and it is the natural way...) but with libuv, if we touched the loop at all, we cannot unpick context creation in one step just like we can't do anything else related to libuv handle close in one step either. With libuv, for fatal context creation errors, we would have to instead treat them as not immediately fatal, create an incomplete context that has already started the destroy flow by the time it leaves lws_destroy_context(), let you start the loop and enter the normal context destroy flow with this half-baked context. I pushed a patch on main + v4.1-stable that detects if it's on libuv + foreign and if the context creation is past the point that it has created handles on the foreign loop, to instead fail by calling destroy_context() and leaving with the half-baked, self-destructing failed context returned. This solves the crash on your example. |
When using a foreign libuv loop, context creation may fail after adding handles to the foreign loop... if so, it can no longer deal with the fatal error by unpicking the created context and returning NULL... it has to brazen it out with a half-baked context that has already started the destroy flow and allow the foreign loop to close out the handles the usual way for libuv. #2129
When using a foreign libuv loop, context creation may fail after adding handles to the foreign loop... if so, it can no longer deal with the fatal error by unpicking the created context and returning NULL... it has to brazen it out with a half-baked context that has already started the destroy flow and allow the foreign loop to close out the handles the usual way for libuv. #2129
When using a foreign libuv loop, context creation may fail after adding handles to the foreign loop... if so, it can no longer deal with the fatal error by unpicking the created context and returning NULL... it has to brazen it out with a half-baked context that has already started the destroy flow and allow the foreign loop to close out the handles the usual way for libuv. #2129
When using a foreign libuv loop, context creation may fail after adding handles to the foreign loop... if so, it can no longer deal with the fatal error by unpicking the created context and returning NULL... it has to brazen it out with a half-baked context that has already started the destroy flow and allow the foreign loop to close out the handles the usual way for libuv. #2129
When using a foreign libuv loop, context creation may fail after adding handles to the foreign loop... if so, it can no longer deal with the fatal error by unpicking the created context and returning NULL... it has to brazen it out with a half-baked context that has already started the destroy flow and allow the foreign loop to close out the handles the usual way for libuv. #2129
Hi,
I have prepared a minimal (I hope not too minimal) example that crashes during uv_run.
The important thing is that the lws_create_context has to fail to create a context. My approach was that I set info.port to some already taken port on my pc.
Used libraries lws 4.1.4, uv 1.35.0
The text was updated successfully, but these errors were encountered: