Re: [Vala] Need help in debugging async code

[Michele Dionisio]

I'm sorry the url is: https://bugzilla.gnome.org/show_bug.cgi?id=772084

2016-09-27 22:38 GMT+02:00 Michele Dionisio :
> I think that now the patch is ok. I have add a bug for that on gnome bugzilla:
> https://bugzilla.gnome.org/show_bug.cgi?id=772084
>
> regards
>
> 2016-09-24 10:33 GMT+02:00 Nor Jaidi Tuah :
>>
>>> now,
>>>
>>> _state_in_progress_ is assigned to -1 at beginning
>>> the check if
>>>
>>> _state_in_progress_ == _state_ is move before the switch to work in
>>> any state.
>>>
>>
>> That won't work either.
>>
>> The fundamental problem is that the caller
>> that calls the callback (the mainloop or
>> whatever alternative you have in mind) must
>> be able to detect when the async method has
>> progressed to the next state. For the mainloop
>> solution, this is trivial. The alternative
>> you have in mind (that calls before yield)
>> must look at _state_ and _state_in_progress_;
>> otherwise, it may livelock.
>>
>> There is no way you can solve this by tweaking
>> async only[1]; you must also tweak the callback caller.
>> I don't think the Vala community would accept that.
>>
>>
>>
>> [1] Of course I may be wrong in this assertion.
>>
>> Nice day
>> Nor Jaidi Tuah
>>
>>
>>
>>
>> PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you 
>> are neither the addressee (intended recipient) nor an authorised recipient 
>> of the addressee, and have received this message in error, please destroy 
>> this message (including attachments) and notify the sender immediately. 
>> STRICT PROHIBITION: This message, whether in part or in whole, should not be 
>> reviewed, retained, copied, reused, disclosed, distributed or used for any 
>> purpose whatsoever. Such unauthorised use may be unlawful and may contain 
>> material protected by the Official Secrets Act (Cap 153) of the Laws of 
>> Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei 
>> Darussalam, accept[s] no responsibility for loss or damage arising from the 
>> use of this message in any manner whatsoever. Our messages are checked for 
>> viruses but we do not accept liability for any viruses which may be 
>> transmitted in or with this message.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Need help in debugging async code

[Michele Dionisio]

I think that now the patch is ok. I have add a bug for that on gnome bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=772084

regards

2016-09-24 10:33 GMT+02:00 Nor Jaidi Tuah :
>
>> now,
>>
>> _state_in_progress_ is assigned to -1 at beginning
>> the check if
>>
>> _state_in_progress_ == _state_ is move before the switch to work in
>> any state.
>>
>
> That won't work either.
>
> The fundamental problem is that the caller
> that calls the callback (the mainloop or
> whatever alternative you have in mind) must
> be able to detect when the async method has
> progressed to the next state. For the mainloop
> solution, this is trivial. The alternative
> you have in mind (that calls before yield)
> must look at _state_ and _state_in_progress_;
> otherwise, it may livelock.
>
> There is no way you can solve this by tweaking
> async only[1]; you must also tweak the callback caller.
> I don't think the Vala community would accept that.
>
>
>
> [1] Of course I may be wrong in this assertion.
>
> Nice day
> Nor Jaidi Tuah
>
>
>
>
> PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you 
> are neither the addressee (intended recipient) nor an authorised recipient of 
> the addressee, and have received this message in error, please destroy this 
> message (including attachments) and notify the sender immediately. STRICT 
> PROHIBITION: This message, whether in part or in whole, should not be 
> reviewed, retained, copied, reused, disclosed, distributed or used for any 
> purpose whatsoever. Such unauthorised use may be unlawful and may contain 
> material protected by the Official Secrets Act (Cap 153) of the Laws of 
> Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei 
> Darussalam, accept[s] no responsibility for loss or damage arising from the 
> use of this message in any manner whatsoever. Our messages are checked for 
> viruses but we do not accept liability for any viruses which may be 
> transmitted in or with this message.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Need help in debugging async code

[Michele Dionisio]

many thanks for your test and feedback.
Now I'will spend more than 2 minutes to make the fix, spending more time
understanding and testing.

I have undestand exactly way the patch if not working, and everything came
from from my mistake undestanding how vala works.

for example. When you call

 test2.begin(, end_callback);

the end_callback is not executed at the end of test2 but it is called from
mainloop (if it is on state0). This is the reason way the mainloop is
mandatory for using async.

Now I have fix all, and seams working but vala does not work as before. for
example (vala async sleep):

public async void nap (uint interval, int priority = GLib.Priority.DEFAULT)
{
  GLib.Timeout.add (interval, () => {
  nap.callback ();
  return false;
}, priority);
  yield;
}
private async void do_stuff () {
  yield nap (1000);
}
private static int main (string[] args) {
  GLib.MainLoop loop = new GLib.MainLoop ();
  do_stuff.begin ((obj, async_res) => {
  loop.quit ();
});
  loop.run ();
  return 0;
}


does not work because loop.quit (); is executed before  loop.run ();.

so continue to work on it before send again a new patch

2016-09-24 10:33 GMT+02:00 Nor Jaidi Tuah :

>
> > now,
> >
> > _state_in_progress_ is assigned to -1 at beginning
> > the check if
> >
> > _state_in_progress_ == _state_ is move before the switch to work in
> > any state.
> >
>
> That won't work either.
>
> The fundamental problem is that the caller
> that calls the callback (the mainloop or
> whatever alternative you have in mind) must
> be able to detect when the async method has
> progressed to the next state. For the mainloop
> solution, this is trivial. The alternative
> you have in mind (that calls before yield)
> must look at _state_ and _state_in_progress_;
> otherwise, it may livelock.
>
> There is no way you can solve this by tweaking
> async only[1]; you must also tweak the callback caller.
> I don't think the Vala community would accept that.
>
>
>
> [1] Of course I may be wrong in this assertion.
>
> Nice day
> Nor Jaidi Tuah
>
>
>
>
> PRIVILEGED/CONFIDENTIAL information may be contained in this message. If
> you are neither the addressee (intended recipient) nor an authorised
> recipient of the addressee, and have received this message in error, please
> destroy this message (including attachments) and notify the sender
> immediately. STRICT PROHIBITION: This message, whether in part or in whole,
> should not be reviewed, retained, copied, reused, disclosed, distributed or
> used for any purpose whatsoever. Such unauthorised use may be unlawful and
> may contain material protected by the Official Secrets Act (Cap 153) of the
> Laws of Brunei Darussalam. DISCLAIMER: We/This Department/The Government of
> Brunei Darussalam, accept[s] no responsibility for loss or damage arising
> from the use of this message in any manner whatsoever. Our messages are
> checked for viruses but we do not accept liability for any viruses which
> may be transmitted in or with this message.
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Need help in debugging async code

[Nor Jaidi Tuah]

> now,
>
> _state_in_progress_ is assigned to -1 at beginning
> the check if
>
> _state_in_progress_ == _state_ is move before the switch to work in
> any state.
> 

That won't work either.

The fundamental problem is that the caller
that calls the callback (the mainloop or
whatever alternative you have in mind) must
be able to detect when the async method has
progressed to the next state. For the mainloop
solution, this is trivial. The alternative
you have in mind (that calls before yield)
must look at _state_ and _state_in_progress_;
otherwise, it may livelock.

There is no way you can solve this by tweaking
async only[1]; you must also tweak the callback caller.
I don't think the Vala community would accept that.



[1] Of course I may be wrong in this assertion.

Nice day
Nor Jaidi Tuah




PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you 
are neither the addressee (intended recipient) nor an authorised recipient of 
the addressee, and have received this message in error, please destroy this 
message (including attachments) and notify the sender immediately. STRICT 
PROHIBITION: This message, whether in part or in whole, should not be reviewed, 
retained, copied, reused, disclosed, distributed or used for any purpose 
whatsoever. Such unauthorised use may be unlawful and may contain material 
protected by the Official Secrets Act (Cap 153) of the Laws of Brunei 
Darussalam. DISCLAIMER: We/This Department/The Government of Brunei Darussalam, 
accept[s] no responsibility for loss or damage arising from the use of this 
message in any manner whatsoever. Our messages are checked for viruses but we 
do not accept liability for any viruses which may be transmitted in or with 
this message.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Need help in debugging async code

[Michele Dionisio]

absolutly not tested my last patch attached that teorically solve all the issue:

now,

_state_in_progress_ is assigned to -1 at beginning
the check if

_state_in_progress_ == _state_ is move before the switch to work in any state.

Do you think that is good now?

2016-09-24 5:46 GMT+02:00 Nor Jaidi Tuah :
> If I understand your patch correctly, it would generate
> something like this:
>
>
>if (_data_->_state_ != 1) {
>   _data_->_state = 1;
>   return FALSE;
>}
>else {
>   // callback already called
>}
>etc. etc.
>
>
> I don't think that's going to work with your use case.
> _data_->_state_ would be stuck at 0 if you call the
> callback before yield.
>
> _state_in_progress_ simply doesn't help.
>
>
>
> Nice day
> Nor Jaidi Tuah
>
>
>
> PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you 
> are neither the addressee (intended recipient) nor an authorised recipient of 
> the addressee, and have received this message in error, please destroy this 
> message (including attachments) and notify the sender immediately. STRICT 
> PROHIBITION: This message, whether in part or in whole, should not be 
> reviewed, retained, copied, reused, disclosed, distributed or used for any 
> purpose whatsoever. Such unauthorised use may be unlawful and may contain 
> material protected by the Official Secrets Act (Cap 153) of the Laws of 
> Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei 
> Darussalam, accept[s] no responsibility for loss or damage arising from the 
> use of this message in any manner whatsoever. Our messages are checked for 
> viruses but we do not accept liability for any viruses which may be 
> transmitted in or with this message.
diff --git a/codegen/valaccodemethodmodule.vala b/codegen/valaccodemethodmodule.vala
index d147eb1..cbd6e1a 100644
--- a/codegen/valaccodemethodmodule.vala
+++ b/codegen/valaccodemethodmodule.vala
@@ -456,6 +456,14 @@ public abstract class Vala.CCodeMethodModule : CCodeStructModule {
 		if (!m.is_abstract || (m.is_abstract && current_type_symbol is Class)) {
 			if (m.body != null) {
 if (m.coroutine) {
+	ccode.open_if(
+		new CCodeBinaryExpression(CCodeBinaryOperator.EQUALITY, 
+			new CCodeMemberAccess.pointer (new CCodeIdentifier ("_data_"), "_state_in_progress_"), 
+			new CCodeMemberAccess.pointer (new CCodeIdentifier ("_data_"), "_state_") ) );
+	ccode.add_statement (new CCodeComment ("callback is called too early before that yield stantment is really reached"));
+	ccode.add_return (new CCodeConstant ("FALSE"));
+	ccode.close();
+
 	ccode.open_switch (new CCodeMemberAccess.pointer (new CCodeIdentifier ("_data_"), "_state_"));
 
 	// initial coroutine state
@@ -475,7 +483,8 @@ public abstract class Vala.CCodeMethodModule : CCodeStructModule {
 	ccode.close ();
 
 	// coroutine body
-	ccode.add_label ("_state_0");
+	ccode.add_label ("_state_0");	
+	ccode.add_assignment (new CCodeMemberAccess.pointer (new CCodeIdentifier ("_data_"), "_state_in_progress_"), new CCodeConstant ("0"));
 }
 
 if (m.closure) {
diff --git a/codegen/valagasyncmodule.vala b/codegen/valagasyncmodule.vala
index 928e67b..6a24300 100644
--- a/codegen/valagasyncmodule.vala
+++ b/codegen/valagasyncmodule.vala
@@ -28,6 +28,7 @@ public class Vala.GAsyncModule : GtkModule {
 		var data = new CCodeStruct ("_" + dataname);
 
 		data.add_field ("int", "_state_");
+		data.add_field ("int", "_state_in_progress_");
 		data.add_field ("GObject*", "_source_object_");
 		data.add_field ("GAsyncResult*", "_res_");
 		data.add_field ("GSimpleAsyncResult*", "_async_result");
@@ -200,6 +201,7 @@ public class Vala.GAsyncModule : GtkModule {
 
 		ccode.add_declaration (dataname + "*", new CCodeVariableDeclarator ("_data_"));
 		ccode.add_assignment (data_var, dataalloc);
+		ccode.add_assignment (new CCodeMemberAccess.pointer (new CCodeIdentifier ("_data_"), "_state_in_progress_"), new CCodeConstant ("-1"));
 
 		var create_result = new CCodeFunctionCall (new CCodeIdentifier ("g_simple_async_result_new"));
 
@@ -663,10 +665,18 @@ public class Vala.GAsyncModule : GtkModule {
 
 		if (stmt.yield_expression == null) {
 			int state = next_coroutine_state++;
-
+			ccode.open_if(
+new CCodeBinaryExpression(CCodeBinaryOperator.INEQUALITY, 
+	new CCodeMemberAccess.pointer (new CCodeIdentifier ("_data_"), "_state_"), 
+	new CCodeConstant (state.to_string ()) ) );
 			ccode.add_assignment (new CCodeMemberAccess.pointer (new CCodeIdentifier ("_data_"), "_state_"), new CCodeConstant (state.to_string ()));
 			ccode.add_return (new CCodeConstant ("FALSE"));
+			ccode.add_else();
+			ccode.add_statement (new CCodeComment ("callback to wakeup yield is already called, so no wait"));
+			ccode.close();
+			
 			ccode.add_label ("_state_%d".printf (state));
+			ccode.add_assignment (new CCodeMemberAccess.pointer (new CCodeIdentifier ("_data_"), 

Re: [Vala] Need help in debugging async code

[michele . dionisio]

Yes state 0 is not safe yet. I have to find -state-in-progress and implement 
the same check.

What do you thinl. It is a good odea to continue to work on it or it is useless?

Il sab set 24 05:46:34 2016 GMT+0200, Nor Jaidi Tuah scrive:
> If I understand your patch correctly, it would generate
> something like this:
> 
> 
>if (_data_->_state_ != 1) {
>   _data_->_state = 1;
>   return FALSE;
>}
>else {
>   // callback already called
>}
>etc. etc.
> 
> 
> I don't think that's going to work with your use case.
> _data_->_state_ would be stuck at 0 if you call the
> callback before yield.
> 
> _state_in_progress_ simply doesn't help.
> 
> 
> 
> Nice day
> Nor Jaidi Tuah
> 
> 
> 
> PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you 
> are neither the addressee (intended recipient) nor an authorised recipient of 
> the addressee, and have received this message in error, please destroy this 
> message (including attachments) and notify the sender immediately. STRICT 
> PROHIBITION: This message, whether in part or in whole, should not be 
> reviewed, retained, copied, reused, disclosed, distributed or used for any 
> purpose whatsoever. Such unauthorised use may be unlawful and may contain 
> material protected by the Official Secrets Act (Cap 153) of the Laws of 
> Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei 
> Darussalam, accept[s] no responsibility for loss or damage arising from the 
> use of this message in any manner whatsoever. Our messages are checked for 
> viruses but we do not accept liability for any viruses which may be 
> transmitted in or with this message.
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Need help in debugging async code

[Nor Jaidi Tuah]

If I understand your patch correctly, it would generate
something like this:


   if (_data_->_state_ != 1) {
  _data_->_state = 1;
  return FALSE;
   }
   else {
  // callback already called
   }
   etc. etc.


I don't think that's going to work with your use case.
_data_->_state_ would be stuck at 0 if you call the
callback before yield.

_state_in_progress_ simply doesn't help.



Nice day
Nor Jaidi Tuah



PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you 
are neither the addressee (intended recipient) nor an authorised recipient of 
the addressee, and have received this message in error, please destroy this 
message (including attachments) and notify the sender immediately. STRICT 
PROHIBITION: This message, whether in part or in whole, should not be reviewed, 
retained, copied, reused, disclosed, distributed or used for any purpose 
whatsoever. Such unauthorised use may be unlawful and may contain material 
protected by the Official Secrets Act (Cap 153) of the Laws of Brunei 
Darussalam. DISCLAIMER: We/This Department/The Government of Brunei Darussalam, 
accept[s] no responsibility for loss or damage arising from the use of this 
message in any manner whatsoever. Our messages are checked for viruses but we 
do not accept liability for any viruses which may be transmitted in or with 
this message.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Need help in debugging async code

[michele . dionisio]

Vala implement async like in 
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

To avoid the limitation of stack usage (and to implement clousure) vala use the 
heap. Also the  state is in the heap. I have only add a check to check if a 
specific state is already executed. 

There is no multithead implication. It is only a more safe way to do the same 
thinks, but more safe.

About performance. Surellyif you develop a gui is not a problem. If you develop 
a web server that is managing a lot of asyncronous request the story is 
different (also because the glib mainloop is not so quick).

When I found few times I will try to write some test, but if in the mean times 
someone can test it I will be very happy. 

Il ven set 23 02:08:35 2016 GMT+0200, Nor Jaidi Tuah scrive:
> 
> > Idle.add(myfunc.callback) is not good for 2 reason:
> > 1. performance. you go back to the mainloop
> > 2. Idle.add has to have less priority that the function that you have
> > to wakeup.
> > 
> 
> Is the mainloop dispatch performance really
> inefficient? Just wondering here because I
> honestly do not know.
> 
> If your patch changes or completely remove
> the async "barriers" then you might as well
> use multi-threading.
> 
> Nice day
> Nor Jaidi Tuah
> 
> 
> 
> PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you 
> are neither the addressee (intended recipient) nor an authorised recipient of 
> the addressee, and have received this message in error, please destroy this 
> message (including attachments) and notify the sender immediately. STRICT 
> PROHIBITION: This message, whether in part or in whole, should not be 
> reviewed, retained, copied, reused, disclosed, distributed or used for any 
> purpose whatsoever. Such unauthorised use may be unlawful and may contain 
> material protected by the Official Secrets Act (Cap 153) of the Laws of 
> Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei 
> Darussalam, accept[s] no responsibility for loss or damage arising from the 
> use of this message in any manner whatsoever. Our messages are checked for 
> viruses but we do not accept liability for any viruses which may be 
> transmitted in or with this message.
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Need help in debugging async code

[Nor Jaidi Tuah]

> Idle.add(myfunc.callback) is not good for 2 reason:
> 1. performance. you go back to the mainloop
> 2. Idle.add has to have less priority that the function that you have
> to wakeup.
> 

Is the mainloop dispatch performance really
inefficient? Just wondering here because I
honestly do not know.

If your patch changes or completely remove
the async "barriers" then you might as well
use multi-threading.

Nice day
Nor Jaidi Tuah



PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you 
are neither the addressee (intended recipient) nor an authorised recipient of 
the addressee, and have received this message in error, please destroy this 
message (including attachments) and notify the sender immediately. STRICT 
PROHIBITION: This message, whether in part or in whole, should not be reviewed, 
retained, copied, reused, disclosed, distributed or used for any purpose 
whatsoever. Such unauthorised use may be unlawful and may contain material 
protected by the Official Secrets Act (Cap 153) of the Laws of Brunei 
Darussalam. DISCLAIMER: We/This Department/The Government of Brunei Darussalam, 
accept[s] no responsibility for loss or damage arising from the use of this 
message in any manner whatsoever. Our messages are checked for viruses but we 
do not accept liability for any viruses which may be transmitted in or with 
this message.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Need help in debugging async code

[Michele Dionisio]

Hi all. I have implemented a patch for vala for safe manage situation
like the one describe on this discution. The solution to call
Idle.add(myfunc.callback) is not good for 2 reason:
1. performance. you go back to the mainloop
2. Idle.add has to have less priority that the function that you have to wakeup.

my patch is attached. Can you test this patch with your code without
modification for  Idle.add(myfunc.callback) . If it is working I will
try to put in on vala bugzilla, and, if we are lucky, it will be
integrated officially.

regards and thanks for any feedback


2016-03-20 14:02 GMT+01:00 mar...@saepia.net :
> Felipe, SIGSTOP is real signal issued by the OS that has stopped the
> execution.
>
> Michele, it seems you were right. I've changed all callback() calls to
> Idle.add(myfunc.callback) so I am 100% sure that they are async and crashes
> stopped to occur.
>
> I must admit that it was one of the weirdest bugs I've encountered ever. It
> caused for instance Soup.Session from libsoup to stop using custom
> TlsDatabase after some time and returing SSL error for all connections, or
> crashes in GLib's memory allocators.
>
> Awkward. I think such warning that code must be async in 100% cases should
> be explicitely added to the documentation.
>
> m.
>
> 2016-03-18 16:29 GMT+01:00 Felipe Lavratti :
>>
>> Hey, Why did you get a SIGSTOP on top of the stack trace? Is it emitted
>> from the code you use to print the stacktrace or it is the real signal that
>> stopped execution?
>>
>> On Fri, Mar 18, 2016 at 6:22 AM mar...@saepia.net 
>> wrote:
>>>
>>> Felipe, it's non threaded.
>>>
>>> Michele, good hint! I will check that.
>>>
>>> m.
>>>
>>> 2016-03-18 6:47 GMT+01:00 :

 A crash can happes if you call the callback to wakeup before the yield.
 Are you completly sure that your code is completly asyncrounous in any
 condition.

 Il ven mar 18 01:05:05 2016 GMT+0100, Felipe Lavratti scrive:
 > Hey Marcin,
 >
 > Just wondering,
 > Is your program using threading or any threaded object that is handled
 > in
 > this part of code?
 >
 >
 >
 >
 > On Thu, Mar 17, 2016 at 20:44 mar...@saepia.net 
 > wrote:
 >
 > > Hi all,
 > >
 > > I encounter random crashes in my app, which (it's my guess) is
 > > triggered
 > > when I call callback in async method.
 > >
 > > Such as
 > >
 > > public async void something() {
 > >   SourceFunc callback_ref = something.callback;
 > >
 > >   do_something_that_calls_another_callback(() => {
 > > callback_ref(); // here's crash happening. approximately 1/1
 > > calls
 > >   });
 > >
 > >   yield;
 > > }
 > >
 > > The chain of async calls is nested.
 > >
 > > I get stack traces like this:
 > >
 > >
 > > https://gist.githubusercontent.com/mspanc/9ca4795f48e56149a9a2/raw/9be534c66409b26820a66d54f8610f2aa6306e1e/gistfile1.txt
 > >
 > > It's rather hard to believe that such basic thing as memory
 > > allocation is
 > > broken in GLib.
 > >
 > > Crash happens totally randomly, once per 1-3 days. You can imagine
 > > how hard
 > > is to collect test cases. I am trying to hunt more stack traces in
 > > order to
 > > find a pattern, but maybe in the meantime anyone here can share
 > > experience
 > > in debugging such issues?
 > >
 > > Or maybe there are some well-known bugs or antipatterns related to
 > > async
 > > functions that should be avoided?
 > >
 > > I use GLib 2.44 & Vala 0.30.0. I will try to upgrade to 2.46 but I
 > > see
 > > nothing related in the changelog.
 > >
 > > m.
 > > ___
 > > vala-list mailing list
 > > vala-list@gnome.org
 > > https://mail.gnome.org/mailman/listinfo/vala-list
 > >
 > ___
 > vala-list mailing list
 > vala-list@gnome.org
 > https://mail.gnome.org/mailman/listinfo/vala-list
 >
>>>
>>>
>
diff --git a/codegen/valaccodemethodmodule.vala b/codegen/valaccodemethodmodule.vala
index d147eb1..1347a26 100644
--- a/codegen/valaccodemethodmodule.vala
+++ b/codegen/valaccodemethodmodule.vala
@@ -476,6 +476,7 @@ public abstract class Vala.CCodeMethodModule : CCodeStructModule {
 
 	// coroutine body
 	ccode.add_label ("_state_0");
+	ccode.add_assignment (new CCodeMemberAccess.pointer (new CCodeIdentifier ("_data_"), "_state_in_progress_"), new CCodeConstant ("0"));
 }
 
 if (m.closure) {
diff --git a/codegen/valagasyncmodule.vala b/codegen/valagasyncmodule.vala
index 928e67b..d0c8001 100644
--- a/codegen/valagasyncmodule.vala
+++ b/codegen/valagasyncmodule.vala
@@ -28,6 +28,7 @@ public class Vala.GAsyncModule : GtkModule {
 		var data = new CCodeStruct 

Re: [Vala] Need help in debugging async code

[mar...@saepia.net]

Felipe, SIGSTOP is real signal issued by the OS that has stopped the
execution.

Michele, it seems you were right. I've changed all callback() calls to
Idle.add(myfunc.callback) so I am 100% sure that they are async and crashes
stopped to occur.

I must admit that it was one of the weirdest bugs I've encountered ever. It
caused for instance Soup.Session from libsoup to stop using custom
TlsDatabase after some time and returing SSL error for all connections, or
crashes in GLib's memory allocators.

Awkward. I think such warning that code must be async in 100% cases should
be explicitely added to the documentation.

m.

2016-03-18 16:29 GMT+01:00 Felipe Lavratti :

> Hey, Why did you get a SIGSTOP on top of the stack trace? Is it emitted
> from the code you use to print the stacktrace or it is the real signal that
> stopped execution?
>
> On Fri, Mar 18, 2016 at 6:22 AM mar...@saepia.net 
> wrote:
>
>> Felipe, it's non threaded.
>>
>> Michele, good hint! I will check that.
>>
>> m.
>>
>> 2016-03-18 6:47 GMT+01:00 :
>>
>>> A crash can happes if you call the callback to wakeup before the yield.
>>> Are you completly sure that your code is completly asyncrounous in any
>>> condition.
>>>
>>> Il ven mar 18 01:05:05 2016 GMT+0100, Felipe Lavratti scrive:
>>> > Hey Marcin,
>>> >
>>> > Just wondering,
>>> > Is your program using threading or any threaded object that is handled
>>> in
>>> > this part of code?
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, Mar 17, 2016 at 20:44 mar...@saepia.net 
>>> wrote:
>>> >
>>> > > Hi all,
>>> > >
>>> > > I encounter random crashes in my app, which (it's my guess) is
>>> triggered
>>> > > when I call callback in async method.
>>> > >
>>> > > Such as
>>> > >
>>> > > public async void something() {
>>> > >   SourceFunc callback_ref = something.callback;
>>> > >
>>> > >   do_something_that_calls_another_callback(() => {
>>> > > callback_ref(); // here's crash happening. approximately 1/1
>>> calls
>>> > >   });
>>> > >
>>> > >   yield;
>>> > > }
>>> > >
>>> > > The chain of async calls is nested.
>>> > >
>>> > > I get stack traces like this:
>>> > >
>>> > >
>>> https://gist.githubusercontent.com/mspanc/9ca4795f48e56149a9a2/raw/9be534c66409b26820a66d54f8610f2aa6306e1e/gistfile1.txt
>>> > >
>>> > > It's rather hard to believe that such basic thing as memory
>>> allocation is
>>> > > broken in GLib.
>>> > >
>>> > > Crash happens totally randomly, once per 1-3 days. You can imagine
>>> how hard
>>> > > is to collect test cases. I am trying to hunt more stack traces in
>>> order to
>>> > > find a pattern, but maybe in the meantime anyone here can share
>>> experience
>>> > > in debugging such issues?
>>> > >
>>> > > Or maybe there are some well-known bugs or antipatterns related to
>>> async
>>> > > functions that should be avoided?
>>> > >
>>> > > I use GLib 2.44 & Vala 0.30.0. I will try to upgrade to 2.46 but I
>>> see
>>> > > nothing related in the changelog.
>>> > >
>>> > > m.
>>> > > ___
>>> > > vala-list mailing list
>>> > > vala-list@gnome.org
>>> > > https://mail.gnome.org/mailman/listinfo/vala-list
>>> > >
>>> > ___
>>> > vala-list mailing list
>>> > vala-list@gnome.org
>>> > https://mail.gnome.org/mailman/listinfo/vala-list
>>> >
>>>
>>
>>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Need help in debugging async code

[Felipe Lavratti]

Hey Marcin,

Just wondering,
Is your program using threading or any threaded object that is handled in
this part of code?




On Thu, Mar 17, 2016 at 20:44 mar...@saepia.net  wrote:

> Hi all,
>
> I encounter random crashes in my app, which (it's my guess) is triggered
> when I call callback in async method.
>
> Such as
>
> public async void something() {
>   SourceFunc callback_ref = something.callback;
>
>   do_something_that_calls_another_callback(() => {
> callback_ref(); // here's crash happening. approximately 1/1 calls
>   });
>
>   yield;
> }
>
> The chain of async calls is nested.
>
> I get stack traces like this:
>
> https://gist.githubusercontent.com/mspanc/9ca4795f48e56149a9a2/raw/9be534c66409b26820a66d54f8610f2aa6306e1e/gistfile1.txt
>
> It's rather hard to believe that such basic thing as memory allocation is
> broken in GLib.
>
> Crash happens totally randomly, once per 1-3 days. You can imagine how hard
> is to collect test cases. I am trying to hunt more stack traces in order to
> find a pattern, but maybe in the meantime anyone here can share experience
> in debugging such issues?
>
> Or maybe there are some well-known bugs or antipatterns related to async
> functions that should be avoided?
>
> I use GLib 2.44 & Vala 0.30.0. I will try to upgrade to 2.46 but I see
> nothing related in the changelog.
>
> m.
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Need help in debugging async code

[Felipe Lavratti]

Hey, Why did you get a SIGSTOP on top of the stack trace? Is it emitted
from the code you use to print the stacktrace or it is the real signal that
stopped execution?

On Fri, Mar 18, 2016 at 6:22 AM mar...@saepia.net  wrote:

> Felipe, it's non threaded.
>
> Michele, good hint! I will check that.
>
> m.
>
> 2016-03-18 6:47 GMT+01:00 :
>
>> A crash can happes if you call the callback to wakeup before the yield.
>> Are you completly sure that your code is completly asyncrounous in any
>> condition.
>>
>> Il ven mar 18 01:05:05 2016 GMT+0100, Felipe Lavratti scrive:
>> > Hey Marcin,
>> >
>> > Just wondering,
>> > Is your program using threading or any threaded object that is handled
>> in
>> > this part of code?
>> >
>> >
>> >
>> >
>> > On Thu, Mar 17, 2016 at 20:44 mar...@saepia.net 
>> wrote:
>> >
>> > > Hi all,
>> > >
>> > > I encounter random crashes in my app, which (it's my guess) is
>> triggered
>> > > when I call callback in async method.
>> > >
>> > > Such as
>> > >
>> > > public async void something() {
>> > >   SourceFunc callback_ref = something.callback;
>> > >
>> > >   do_something_that_calls_another_callback(() => {
>> > > callback_ref(); // here's crash happening. approximately 1/1
>> calls
>> > >   });
>> > >
>> > >   yield;
>> > > }
>> > >
>> > > The chain of async calls is nested.
>> > >
>> > > I get stack traces like this:
>> > >
>> > >
>> https://gist.githubusercontent.com/mspanc/9ca4795f48e56149a9a2/raw/9be534c66409b26820a66d54f8610f2aa6306e1e/gistfile1.txt
>> > >
>> > > It's rather hard to believe that such basic thing as memory
>> allocation is
>> > > broken in GLib.
>> > >
>> > > Crash happens totally randomly, once per 1-3 days. You can imagine
>> how hard
>> > > is to collect test cases. I am trying to hunt more stack traces in
>> order to
>> > > find a pattern, but maybe in the meantime anyone here can share
>> experience
>> > > in debugging such issues?
>> > >
>> > > Or maybe there are some well-known bugs or antipatterns related to
>> async
>> > > functions that should be avoided?
>> > >
>> > > I use GLib 2.44 & Vala 0.30.0. I will try to upgrade to 2.46 but I see
>> > > nothing related in the changelog.
>> > >
>> > > m.
>> > > ___
>> > > vala-list mailing list
>> > > vala-list@gnome.org
>> > > https://mail.gnome.org/mailman/listinfo/vala-list
>> > >
>> > ___
>> > vala-list mailing list
>> > vala-list@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/vala-list
>> >
>>
>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Need help in debugging async code

[michele . dionisio]

A crash can happes if you call the callback to wakeup before the yield. Are you 
completly sure that your code is completly asyncrounous in any condition.

Il ven mar 18 01:05:05 2016 GMT+0100, Felipe Lavratti scrive:
> Hey Marcin,
> 
> Just wondering,
> Is your program using threading or any threaded object that is handled in
> this part of code?
> 
> 
> 
> 
> On Thu, Mar 17, 2016 at 20:44 mar...@saepia.net  wrote:
> 
> > Hi all,
> >
> > I encounter random crashes in my app, which (it's my guess) is triggered
> > when I call callback in async method.
> >
> > Such as
> >
> > public async void something() {
> >   SourceFunc callback_ref = something.callback;
> >
> >   do_something_that_calls_another_callback(() => {
> > callback_ref(); // here's crash happening. approximately 1/1 calls
> >   });
> >
> >   yield;
> > }
> >
> > The chain of async calls is nested.
> >
> > I get stack traces like this:
> >
> > https://gist.githubusercontent.com/mspanc/9ca4795f48e56149a9a2/raw/9be534c66409b26820a66d54f8610f2aa6306e1e/gistfile1.txt
> >
> > It's rather hard to believe that such basic thing as memory allocation is
> > broken in GLib.
> >
> > Crash happens totally randomly, once per 1-3 days. You can imagine how hard
> > is to collect test cases. I am trying to hunt more stack traces in order to
> > find a pattern, but maybe in the meantime anyone here can share experience
> > in debugging such issues?
> >
> > Or maybe there are some well-known bugs or antipatterns related to async
> > functions that should be avoided?
> >
> > I use GLib 2.44 & Vala 0.30.0. I will try to upgrade to 2.46 but I see
> > nothing related in the changelog.
> >
> > m.
> > ___
> > vala-list mailing list
> > vala-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/vala-list
> >
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Need help in debugging async code

[mar...@saepia.net]

Felipe, it's non threaded.

Michele, good hint! I will check that.

m.

2016-03-18 6:47 GMT+01:00 :

> A crash can happes if you call the callback to wakeup before the yield.
> Are you completly sure that your code is completly asyncrounous in any
> condition.
>
> Il ven mar 18 01:05:05 2016 GMT+0100, Felipe Lavratti scrive:
> > Hey Marcin,
> >
> > Just wondering,
> > Is your program using threading or any threaded object that is handled in
> > this part of code?
> >
> >
> >
> >
> > On Thu, Mar 17, 2016 at 20:44 mar...@saepia.net 
> wrote:
> >
> > > Hi all,
> > >
> > > I encounter random crashes in my app, which (it's my guess) is
> triggered
> > > when I call callback in async method.
> > >
> > > Such as
> > >
> > > public async void something() {
> > >   SourceFunc callback_ref = something.callback;
> > >
> > >   do_something_that_calls_another_callback(() => {
> > > callback_ref(); // here's crash happening. approximately 1/1
> calls
> > >   });
> > >
> > >   yield;
> > > }
> > >
> > > The chain of async calls is nested.
> > >
> > > I get stack traces like this:
> > >
> > >
> https://gist.githubusercontent.com/mspanc/9ca4795f48e56149a9a2/raw/9be534c66409b26820a66d54f8610f2aa6306e1e/gistfile1.txt
> > >
> > > It's rather hard to believe that such basic thing as memory allocation
> is
> > > broken in GLib.
> > >
> > > Crash happens totally randomly, once per 1-3 days. You can imagine how
> hard
> > > is to collect test cases. I am trying to hunt more stack traces in
> order to
> > > find a pattern, but maybe in the meantime anyone here can share
> experience
> > > in debugging such issues?
> > >
> > > Or maybe there are some well-known bugs or antipatterns related to
> async
> > > functions that should be avoided?
> > >
> > > I use GLib 2.44 & Vala 0.30.0. I will try to upgrade to 2.46 but I see
> > > nothing related in the changelog.
> > >
> > > m.
> > > ___
> > > vala-list mailing list
> > > vala-list@gnome.org
> > > https://mail.gnome.org/mailman/listinfo/vala-list
> > >
> > ___
> > vala-list mailing list
> > vala-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/vala-list
> >
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list