I would like to get more details.

Because, if you talk about a Server and asynchronous, may we need to talk about to keep user status data alive in different ways, like a cookie at client side, a temporary file at server or in a database. There are plenty of examples.

Now this bug can be reproduced in a simple program, without​ a server environment?

Created attachment 352461 [details] [review]
Testcase

Daniel: Sorry for the brief explanation. This test-case should hopefully make
things a bit clearer.

Created attachment 352463 [details] [review]
codegen: Keep arrays alive during async server method calls

When calling a co-routine it is the caller's responsibility to ensure
that arrays stay alive for the duration of the call. The GDBus server
code emitted did not do this, resulting in use-after-free.

This example is a little complicate.

I assume your problem is over array argument lifetime, after yield.

In other asynchronous methods I have, yield makes no other Variables goes out of scope.

If an array is going out of scope and is correct because arrays' memory management, then valac should warn.

My obvious solution here is use a reference counting objects to save memory an copy processing.

(In reply to Daniel Espinosa from comment #4)
> This example is a little complicate.
> 
> I assume your problem is over array argument lifetime, after yield.
> 
> In other asynchronous methods I have, yield makes no other Variables goes
> out of scope.
> 
> If an array is going out of scope and is correct because arrays' memory
> management, then valac should warn.
> 
> My obvious solution here is use a reference counting objects to save memory
> an copy processing.

Arrays are special in co-routines, Vala will not make a copy of them. It
used to do this, but this made it impossible to implement GIO APIs where
a co-routine is given an array and asked to write into it.

Because of this it is the caller's responsibility to keep arrays alive
while an async call is still in progress. In the case of Vala-generated
GDBus server code, the code it generates is such a caller whenever dealing
with a co-routine. So this means the code it generates needs to keep arrays
alive until the call completes. This is only an issue if the co-routine
actually uses the array argument after the first yield.

Created attachment 352465 [details] [review]
codegen: Keep arrays alive during async server method calls

Fixed handling of out parameters. All tests green.

Created attachment 370254 [details] [review]
codegen: Keep arrays alive during async server method calls

When calling a co-routine it is the caller's responsibility to ensure
that arrays stay alive for the duration of the call. The GDBus server
code emitted did not do this, resulting in use-after-free.

Attachment 370254 [details] pushed as 650415b - codegen: Keep arrays alive during async server method calls