Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scheduler.await termination delegate accesses non valid data #644

Open
matthias-wende-sociomantic opened this issue Oct 11, 2018 · 3 comments

Comments

@matthias-wende-sociomantic
Copy link
Contributor

matthias-wende-sociomantic commented Oct 11, 2018

This problem occurs during shutting down the application after calling theScheduler.shutdown and causes the app to SEGFAULT. Note that it is tested in D2 only.

It seems that in at least one case the context variable is not valid when accessed from the delegate.
https://github.com/sociomantic-tsunami/ocean/blob/v4.x.x/src/ocean/task/Scheduler.d#L430

Here is the stacktrace:

#0  0x000000000065c7bc in _D5ocean4task4TaskQf9suspendedMFZb (this=0x0) at ./submodules/ocean/src/ocean/task/Task.d:399
#1  0x0000000000696245 in _D5ocean4task9SchedulerQk5awaitMFCQBgQBd4TaskQfMDFQrZvZ9__lambda3MFZv (this=0x7f49a3e4ecd8)
    at ./submodules/ocean/src/ocean/task/Scheduler.d:412
#2  0x000000000065cb8f in _D5ocean4task4TaskQf10entryPointMFZb (this=0x7f499f966d00) at ./submodules/ocean/src/ocean/task/Task.d:489
#3  0x00000000005f247d in _D5ocean4task8internal18FiberPoolWithQueueQu17workerFiberMethodMFZ7runTaskMFZv (this=0x7f4998325f88)
    at ./submodules/ocean/src/ocean/task/internal/FiberPoolWithQueue.d:175
#4  0x00000000005f23ba in _D5ocean4task8internal18FiberPoolWithQueueQu17workerFiberMethodMFZv (this=0x7f49a3e58e00)
    at ./submodules/ocean/src/ocean/task/internal/FiberPoolWithQueue.d:189
#5  0x00000000006d3848 in core.thread.Fiber.run() (this=0x7f499f965a00) at src/core/thread.d:4389
#6  0x00000000006d3717 in fiber_entryPoint () at src/core/thread.d:3626
#7  0x0000000000000000 in ?? ()

Exchanging the delegate with a closure as follows fixes the problem but seems not to be a reasonable solution.

auto cl = {
    if (context.suspended())
        theScheduler.delayedResume(context);
};
// this methods stack is guaranteed to still be valid by the time
// task finishes, so we can reference `task` from delegate
task.terminationHook(cl);
@matthias-wende-sociomantic
Copy link
Contributor Author

My explanation was wrong. Both are clojures, so the code should be the same. It's strange that it solved the problem 😕.

@Geod24
Copy link
Contributor

Geod24 commented Oct 31, 2018

Both are clojsures, so the code should be the same.

Are they ? I see this code and d1to2fix should stick a scope there, which makes any direct call to not GC-allocate the context.

So the code with auto will GC-allocate, while passing the dg directly will not GC-allocate, but run into the problem you mentioned. That might be by design though.
If you turn the auto into scope the problem should manifest itself again.

@matthias-wende-sociomantic
Copy link
Contributor Author

Yep, you are right there is a scope in the d2 version. I forgot that I'm using the d1tod2fixed version of ocean. Thanks :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants