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 <felipe...@gmail.com>:
> 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 <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 <michele.dioni...@gmail.com>:
>>
>>> 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 <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/10000
>>> 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
