Jun 25 2023
Dec 4 2020
Can't reproduce as of 338138c9d2007e75ebb7f5e97dc5894cb125193d.
Jan 5 2020
Dec 26 2019
A simple example without a value would be:
I think we may even be able to used std::future and std::packaged_task directly, which I would prefer to another custom future/promise.
Dec 21 2019
Dec 20 2019
Thanks that did the trick.
Dec 19 2019
OK, I have reverted the commit in master now. Sink tests pass again.
To be honest I think it makes most sense to revert back to default constructing T for the time being.
Dec 18 2019
There's no easy way how to fix this without reverting back to default-constructing T in Future<T>::Future().
It's not exactly the lifetime- it's a more deep-rooted issue with error handling.
Dec 17 2019
Generally, I'm wondering if I should deprecate this API and introduce a promise-future based API, where, instead of being passed a future from KAsync, the continuation would construct a Promise object internally a return a Future that KAsync would wait for....internally the continuation would own the Promise - it's closer to the common promise-future pattern and solves the lifetime issue, since the Promise is owned by the continuation, rather than by KAsync (which only holds the Future).
I can probably solve the life-time of the future, however you are still calling setError twice on it, which should be undefined behavior - or, following what std::future does, would, well, not throw (because Qt), but might as well assert.
Hmm, I believe the bug might be in the Sink code. Here specifically, it's ResourceControl::flush():
Dec 15 2019
tests/notificationtest in sink will produce a similar crash.
Dec 13 2019
I have rebuilt the flatpak completely and can reproduce the crash. Also, I can reproduce the crash outside of the flatpak again, not sure what I did above.
Dec 9 2019
Ever since I have rebuilt a with -fsanitize=address I can no longer reproduce outside of the flatpak, so there's a chance that the fault is with flatpaks internal build chaching that somehow results in something that crashes (I can't think of a reasonable scenario, but who knows).
I'll try to completely rebuild the flatpak as well and see if this fixes the issue.
Dec 6 2019
Nothing very obvious from the address sanitizer so far, but I also haven't managed to run kube with it yet (only sinksh).
I'll try that. Next week is fine, no hurry.
Looks like some memory issue...could you try compiling with -fsanitize=address? I won't get to look into it properly before some time next week, sorry.
Dec 4 2019
FWIW; I have attempted but failed to reproduce this in a kasync testcase. I can reproduce it by starting latest kube with latest sink and latest kasync, and I can reproduce the crash in both flatpak (which I have now reverted to kasync 0.3.0), and a locally built kube.
Dec 3 2019
May 20 2019
I'm building with clang on windows meanwhile, and that works fine.
Mar 2 2018
Apr 6 2017
The guard facility should probably be added on the job level, otherwise subjobs can't use the facility to protect themselves.
Guards could work similarly to the context. Call .guard(QObject*/smart pointer) and be sure that no continuation will be called if the guard is gone.
Mar 31 2017
Or just do .exec(guard);
The guard object could be any qobject/smart pointer/...
Mar 8 2017
Nice!
Fixed in master (see the commit message for details).
Mar 3 2017
Mar 2 2017
Mar 1 2017
I'd like to do a first 0.1 release as soon as the frameworks removal is merged.
Feb 10 2017
Thanks for the patch! (I applied it locally and will push it in a bit).
Feb 6 2017
Ok, I thought that clang had a different syntax for attributes. I found the same error in Sink, this is a patch for it.