Exposed secondary toolbar causes intermittent Activity lockup on "Stop" requiring a force-quit

[garycmartin]

F11 sugar-jhbuild environment:

Having an exposed secondary toolbar causes intermittent Activity lockup when you try and Stop it. The activity will just stop responding to all UI attempts, but if you use the Frame Activitytray palette and issue a second Stop from there, after 5-10sec Metacity will pop-up a dialogue "<activity name> is not responding (force-quit) (wait)" (see attached screen shots).

I was intermittently seeing this while working on Write toolbars (I launched that a 100 or so times while working/testing, perhaps saw 5-10 lockups) . Then I saw the same thing intermittently while working on Calculate toolbars. Panicking that it's something I might be doing I've just tested the latest Browse and after 6 resume -> expose a secondary palette -> stop cycles, it just locked up a well requiring a force-quit, also just tested the same thing in Terminal on the 6th attempt.

To reproduce:

1) Resume any activity with new toolbars from home (e.g. Terminal)
2) Click to lock open one of the secondary toolbars (e.g. Tab toolbar)
3) Click the Stop icon
4) Repeat from step 1 until activity fails to stop

Once the activity has locked up, top shows it running at 50% cpu load, the activity icon in the top frame can be used to stop the activity, after 5-10sec Metacity will provide a force quit dialogue.

[alsroot]

The problem was with cross links in toolbarbox,
attached patch removes all these links.

[alsroot]

Gary, could you recheck issue w/ patch applied,
I didn't manage reproduce metacity dialogs, in my case it was just suspicious gtk warnings in log

[garycmartin]

Replying to alsroot:

Gary, could you recheck issue w/ patch applied,
I didn't manage reproduce metacity dialogs, in my case it was just suspicious gtk warnings in log

Hi Aleksey, after spending quite some trying tonight (different activities/toolbars over several reboots), with the latest sugar-jhbuild, I've not been able to get the toolbar to cause the activity to stop responding when stopped. This is _without_ applying your above patch. I'll keep a look out for this, but it appears some other patch is now avoiding triggering this issue.

[tomeu]

Let's try to reproduce the lockup and apply a fix only when we can verify it actually fixes something.

[alsroot]

The issue which patch intended to fix, was moved to #1389.

[manuq]

Closing this old bug as I've never seen it since I'm involved with the project. Otherwise Gary please reopen it.