Created attachment 12643 [details]
The exception

Your fault.
You give a collection to somebody to process (to Children.keys) and
keep modifying it from other thread.
You'd best pass a clone of the original collection.

Regardless where the problem is, I think this is very bad and should
be fixed before release. Rising priority to P2.

It's caused by 37802 workaround.

37802 is not likely to be fixed until TTV is rewritten, which is
definitely not for 3.6.

True, TaskChildren.refreshKeys has

// #37802 XXX workaround
final Collection finalKeys = keys;
Mutex.EVENT.readAccess(new Runnable() {
    public void run() {
        setKeys(finalKeys);
    }
});

which should probably be amended to e.g.

final Task[] tasks = (Task[])keys.toArray(new Task[keys.size()]);
Mutex.EVENT.readAccess(new Runnable() {
    public void run() {
        setKeys(tasks);
    }
});

or change

keys = parent.getSubtasks();

to

keys = new ArrayList(parent.getSubtasks());

Looks like an easy fix, should do it ASAP. No dependency on issue
#37802 AFAICT.

(BTW I never got this exception myself, for whatever reason.)

It's easy, but the new allocation press on GC and the functionality is
already fighting performance probs.

I can assure you that whatever you are allocating here, Children,
Visualizers, Explorer, ... will allocate ten times as much before
anything gets displayed.

BTW: if you anticipate heavy traffic on setKeys call, you'd better
coalesce the updates. If your scanned generates 100 hits per second,
the user won't read them that fast anyway.

Please, reporter, could you verify fixed issues. Thanks a lot.