issue-#156 adding Coroutines to BlackBox

[Robert]

For the first time since Coroutines were added to BlackBox I've got a problem where I think Coroutines are the natural solution.

I now have what seems like a simple, natural, even elgant solution using iterators (the process of finding this solution was NOT simple or elegant!).

But I am getting quite a lot of low-level Kernel traps, involving illegal memory reads, cascades of small trap boxes, and BlackBox crashing out to Windows. Might there be something flakey in the implementation? Have other people found Coroutines to be reliable?

[Robert]

This is getting tiresome!

The sequence seems to be:

- I have a suspended Coroutine.
- I unload its defining module.
- I edit, and sometimes save, the module's source code.
- I compile the module.

At that point I get an infinite series of low-level traps, resulting, in a few seconds, with BlackBox closing down loosing all my data.

The top line of the trap reads: Illegal address, ad = 00, or ad = 04 (I think, it happens too quickly to make accurate notes).

It doesn't happen every time, maybe about 1 in 10 chance. More work lost!

Update: The last TRAP was called from Kernel.MarkLocals.
Update: The last TRAP was called from Kernel.MarkReferencedCoroutines.
Update: This time is was TrapHandler called from MarkLocals.
Update: ... and MarkLocals was called from FastCollect.

[Josef Templ]

Robert,
there seems to be an issue with coroutines in combination with module unloading followed by a garbage collector cycle.
Something is not cleaned up correctly.

I hope to find the time to check this out in the near future.
Please remind me if it takes too long.

It would be helpful to have a stripped down test case that exhibits the error.
You can call the garbage collector explicitly for forcing a GC cycle.
This may help to get a reproducible error case.

- Josef

[Josef Templ]

Robert,

are you resuming execution of the suspended and unloaded coroutine somehow?

- Josef

[Robert]

are you resuming execution of the suspended and unloaded coroutine somehow?

Not deliberately!

My code is (unfortunately) very far from stripped down, and only crashes infrequently, and not predictably, so creating a simple example test case does not seem to be easy.

The most predictable circumstance seems to be that the crashes occur running the compiler just after unloading my module, but even this is not definite. The last crash occurred running my module.

[Josef Templ]

And it only happens when you unload the suspended coroutine's module, right?
What about stopping the coroutine(s) before unloading the module?
As a workaround, of course, it should not crash.

One thing that can be reproduced easily is a suspicious trap window when
unloading a suspended coroutine's module and resuming the coroutine later.
The trap window displays strange chinese characters, but it never crashes the process
in my experiments. Nevertheless, it is not looking right.

- Josef

[Robert]

And it only happens when you unload the suspended coroutine's module, right?

My normal workflow is:
- Edit
- Ctrl k - Compile
- Ctrl s - Save if no compile errors.
- Unload
- Try new version
& repeat many times ....

The crashes usually occur during the Compile.

[Robert]

What about stopping the coroutine(s) before unloading the module?

Not exactly sure what you are suggesting - I think you mean adding something to the CLOSE section of my module?

[Josef Templ]

What you could also try is to unload all modules that use Coroutines and in addition to unload the module Coroutines themselves.
This terminates Coroutine support and may lead to a more stable behavior with respect to GC.

- Josef

[Robert]

In the last couple of days the main activity of my Coroutines module has changed from being 90% development / 10% use to 10% development / 90% use. I am getting far fewer crashes - 1 two days ago.

I have now added Coroutines.Cleanup to my CLOSE section. I don't really understand what it does. The Docu says "sets main.from = NIL". Is that correct?