GNOME Bugzilla – Bug 741929
Unreachable _state_ generated for async call inside finally block
Last modified: 2017-05-13 16:54:01 UTC
Using git master as of today, Vala will generate a coroutine state value that is unreachable from the internal jump table. I will attach the full file, but this is the relevant part: public async void query_async() throws Error { running = true; try { if (!yield internal_query_async()) return; } finally { try { yield close_query_async(); } catch (Error err) { // ignored } running = false; } } In order to reproduce this, it appears that (a) there has to be a code path within in the try block that will exit the method, and (b) there has to be code executed inside the finally block after the async call there. The generated C code will set the internal _state_ field to a value that is not found in the _co function's jump table. This happens before calling close_query_async(). That in turn leads to a "code should not be reached" hard assertion when it completes.
Created attachment 293305 [details] Test case demonstrating problem
Getting lost in the generated code. I'm not very knowledged about error handling in C generated by vala. So Jurg may have more insights on this.
The problem appears to be that the code in "return;" is emitted twice in the first try.
Ok the problem is in append_scope_free of the gerror module, which emits the finally block twice.
Created attachment 293328 [details] [review] fix finally blocks with async calls What about this patch? Asking for a quick Juerg review. It removes Method.yield_count because it's not correct as finally blocks get emitted twice in C.
Ping!
commit e42314a753a257b7e80967350a72699e7e68428e Author: Luca Bruno <lucabru@src.gnome.org> Date: Wed Dec 24 23:20:58 2014 +0100 codegen: Fix finally blocks with async yields The Method.yield_count is not correct because in C the finally blocks may be emitted twice.