After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 741929 - Unreachable _state_ generated for async call inside finally block
Unreachable _state_ generated for async call inside finally block
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: Async
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2014-12-23 22:20 UTC by Jim Nelson
Modified: 2017-05-13 16:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test case demonstrating problem (920 bytes, text/x-vala)
2014-12-23 22:21 UTC, Jim Nelson
  Details
fix finally blocks with async calls (9.08 KB, patch)
2014-12-24 22:24 UTC, Luca Bruno
committed Details | Review

Description Jim Nelson 2014-12-23 22:20:54 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.
Comment 1 Jim Nelson 2014-12-23 22:21:23 UTC
Created attachment 293305 [details]
Test case demonstrating problem
Comment 2 Luca Bruno 2014-12-24 21:42:26 UTC
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.
Comment 3 Luca Bruno 2014-12-24 21:48:52 UTC
The problem appears to be that the code in "return;" is emitted twice in the first try.
Comment 4 Luca Bruno 2014-12-24 21:53:19 UTC
Ok the problem is in append_scope_free of the gerror module, which emits the finally block twice.
Comment 5 Luca Bruno 2014-12-24 22:24:53 UTC
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.
Comment 6 Michael Gratton 2016-07-03 09:29:42 UTC
Ping!
Comment 7 Rico Tzschichholz 2017-05-13 16:53:55 UTC
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.