[squeak-dev] losing mouse clicks

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] losing mouse clicks

Julian Fitzell-2
On 08.05.2008, at 11:14, Adrian Lienhard wrote:

> Hi,
>
> From time to time it happens that the image gets into a weird state where click
> events are only honored after moving the mouse. For example, in the code
> browser you click on a method but nothing happens until you start moving the
> cursor. The problem does not seem to go away again.
>
> Has anybody else seen this problem? If yes, does a Mantis report exist that I
> have not found?

Gah, this has been biting me constantly in one image after another
over the past 6 weeks (never seen it until then). First It thought it
was a particular image, then it happened in another. So I thought it
was the Windows VM but then it happened with the Mac VM. So then I
figured it must be something MC2 was doing but now it just happened in
a Seaside image. And that was a Pharo image so it's not even specific
to the base image I'm using.

Did anybody ever figure out what the heck is causing this? It's
driving me nuts!!

I did spend a bit of time in one image trying to track it down and it
seemed like lots of mouse events were getting put into the
EventSensor's eventQueue but not being pulled out before
#flushNonKbdEvents was called (it's called often). Changing that
method to leave mouse clicks as well helped for a bit but mouse ups
weren't getting generated. I again hacked around that a bit but it
never worked very well and then it seemed to start getting worse
again.

Help!

Julian

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: losing mouse clicks

Andreas.Raab
Julian Fitzell wrote:
> Did anybody ever figure out what the heck is causing this? It's
> driving me nuts!!

It's users of Sensor>>mouseButtons, Sensor>>shiftPressed etc. The main
suspect in this regard is TransferMorph which does this:

TransferMorph>>step
        self shouldCopy: Sensor shiftPressed.
        self updateCopyIcon

A lingering TransforMorph (which can happen after DnD errors) will
happily eat all your events.

One thing you can try in such a situation is to see whether there is a
TransferMorph hidden somewhere. In addition you could just do a stack
dump whenever someone calls flushNonKbdEvents:

EventSensor>>flushNonKbdEvents

        WorldState addDeferredUIMessage:
                (MessageSend
                        receiver: Transcript
                        selector: #show:
                        argument: thisContext longStack).

[no block in the above since you need the stack eagerly]

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: losing mouse clicks

Julian Fitzell-2
On Sun, Dec 21, 2008 at 8:38 PM, Andreas Raab <[hidden email]> wrote:

> Julian Fitzell wrote:
>>
>> Did anybody ever figure out what the heck is causing this? It's
>> driving me nuts!!
>
> It's users of Sensor>>mouseButtons, Sensor>>shiftPressed etc. The main
> suspect in this regard is TransferMorph which does this:
>
> TransferMorph>>step
>        self shouldCopy: Sensor shiftPressed.
>        self updateCopyIcon
>
> A lingering TransforMorph (which can happen after DnD errors) will happily
> eat all your events.

Thank you, thank you, thank you. This fixed it:

TransferMorph allInstances do: [:ea | ea delete]

(there was a lingering one - it had an omnibrowser method node as a passenger)

Not sure why this is happening so much to me right now but at least I
have a fix.

Julian

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: losing mouse clicks

Bert Freudenberg

On 21.12.2008, at 21:06, Julian Fitzell wrote:

> On Sun, Dec 21, 2008 at 8:38 PM, Andreas Raab <[hidden email]>  
> wrote:
>> Julian Fitzell wrote:
>>>
>>> Did anybody ever figure out what the heck is causing this? It's
>>> driving me nuts!!
>>
>> It's users of Sensor>>mouseButtons, Sensor>>shiftPressed etc. The  
>> main
>> suspect in this regard is TransferMorph which does this:
>>
>> TransferMorph>>step
>>       self shouldCopy: Sensor shiftPressed.
>>       self updateCopyIcon
>>
>> A lingering TransforMorph (which can happen after DnD errors) will  
>> happily
>> eat all your events.
>
> Thank you, thank you, thank you. This fixed it:
>
> TransferMorph allInstances do: [:ea | ea delete]
>
> (there was a lingering one - it had an omnibrowser method node as a  
> passenger)
>
> Not sure why this is happening so much to me right now but at least I
> have a fix.


Oh great! We have encountered this from time to time but never got  
down to the cause. Thanks Andreas!

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: losing mouse clicks

Karl Ramberg
So maybe the TransferMorph>>step should have a 'self  delete' if owner
is not a hand morph? Or is there cases where transferMorphs live by
them self ?

Karl

On 12/21/08, Bert Freudenberg <[hidden email]> wrote:

>
> On 21.12.2008, at 21:06, Julian Fitzell wrote:
>
>> On Sun, Dec 21, 2008 at 8:38 PM, Andreas Raab <[hidden email]>
>> wrote:
>>> Julian Fitzell wrote:
>>>>
>>>> Did anybody ever figure out what the heck is causing this? It's
>>>> driving me nuts!!
>>>
>>> It's users of Sensor>>mouseButtons, Sensor>>shiftPressed etc. The
>>> main
>>> suspect in this regard is TransferMorph which does this:
>>>
>>> TransferMorph>>step
>>>       self shouldCopy: Sensor shiftPressed.
>>>       self updateCopyIcon
>>>
>>> A lingering TransforMorph (which can happen after DnD errors) will
>>> happily
>>> eat all your events.
>>
>> Thank you, thank you, thank you. This fixed it:
>>
>> TransferMorph allInstances do: [:ea | ea delete]
>>
>> (there was a lingering one - it had an omnibrowser method node as a
>> passenger)
>>
>> Not sure why this is happening so much to me right now but at least I
>> have a fix.
>
>
> Oh great! We have encountered this from time to time but never got
> down to the cause. Thanks Andreas!
>
> - Bert -
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: losing mouse clicks

Bert Freudenberg
No, it should be changed to not use Sensor directly.

- Bert -

On 22.12.2008, at 00:12, karl ramberg wrote:

> So maybe the TransferMorph>>step should have a 'self  delete' if owner
> is not a hand morph? Or is there cases where transferMorphs live by
> them self ?
>
> Karl
>
> On 12/21/08, Bert Freudenberg <[hidden email]> wrote:
>>
>> On 21.12.2008, at 21:06, Julian Fitzell wrote:
>>
>>> On Sun, Dec 21, 2008 at 8:38 PM, Andreas Raab <[hidden email]>
>>> wrote:
>>>> Julian Fitzell wrote:
>>>>>
>>>>> Did anybody ever figure out what the heck is causing this? It's
>>>>> driving me nuts!!
>>>>
>>>> It's users of Sensor>>mouseButtons, Sensor>>shiftPressed etc. The
>>>> main
>>>> suspect in this regard is TransferMorph which does this:
>>>>
>>>> TransferMorph>>step
>>>>      self shouldCopy: Sensor shiftPressed.
>>>>      self updateCopyIcon
>>>>
>>>> A lingering TransforMorph (which can happen after DnD errors) will
>>>> happily
>>>> eat all your events.
>>>
>>> Thank you, thank you, thank you. This fixed it:
>>>
>>> TransferMorph allInstances do: [:ea | ea delete]
>>>
>>> (there was a lingering one - it had an omnibrowser method node as a
>>> passenger)
>>>
>>> Not sure why this is happening so much to me right now but at  
>>> least I
>>> have a fix.
>>
>>
>> Oh great! We have encountered this from time to time but never got
>> down to the cause. Thanks Andreas!
>>
>> - Bert -
>>
>>
>>
>>
>




Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: losing mouse clicks

Andreas.Raab
Bert Freudenberg wrote:
> No, it should be changed to not use Sensor directly.

Indeed. This is also subtly broken in the presence of multiple hands.
What it should do is determine the hand that is dragging it, remember
that hand and then use "hand shiftPressed". Unfortunately, this requires
the users of TransferMorph to be fixed so that they pass a valid hand in
the drag process since TransferMorph itself can't easily figure out
which hand is responsible.

Cheers,
   - Andreas

> - Bert -
>
> On 22.12.2008, at 00:12, karl ramberg wrote:
>
>> So maybe the TransferMorph>>step should have a 'self  delete' if owner
>> is not a hand morph? Or is there cases where transferMorphs live by
>> them self ?
>>
>> Karl
>>
>> On 12/21/08, Bert Freudenberg <[hidden email]> wrote:
>>>
>>> On 21.12.2008, at 21:06, Julian Fitzell wrote:
>>>
>>>> On Sun, Dec 21, 2008 at 8:38 PM, Andreas Raab <[hidden email]>
>>>> wrote:
>>>>> Julian Fitzell wrote:
>>>>>>
>>>>>> Did anybody ever figure out what the heck is causing this? It's
>>>>>> driving me nuts!!
>>>>>
>>>>> It's users of Sensor>>mouseButtons, Sensor>>shiftPressed etc. The
>>>>> main
>>>>> suspect in this regard is TransferMorph which does this:
>>>>>
>>>>> TransferMorph>>step
>>>>>      self shouldCopy: Sensor shiftPressed.
>>>>>      self updateCopyIcon
>>>>>
>>>>> A lingering TransforMorph (which can happen after DnD errors) will
>>>>> happily
>>>>> eat all your events.
>>>>
>>>> Thank you, thank you, thank you. This fixed it:
>>>>
>>>> TransferMorph allInstances do: [:ea | ea delete]
>>>>
>>>> (there was a lingering one - it had an omnibrowser method node as a
>>>> passenger)
>>>>
>>>> Not sure why this is happening so much to me right now but at least I
>>>> have a fix.
>>>
>>>
>>> Oh great! We have encountered this from time to time but never got
>>> down to the cause. Thanks Andreas!
>>>
>>> - Bert -
>>>
>>>
>>>
>>>
>>
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: losing mouse clicks

Andreas.Raab
I've added a mantis report and proposed fix here:

   http://bugs.squeak.org/view.php?id=7251

Cheers,
   - Andreas

Andreas Raab wrote:

> Bert Freudenberg wrote:
>> No, it should be changed to not use Sensor directly.
>
> Indeed. This is also subtly broken in the presence of multiple hands.
> What it should do is determine the hand that is dragging it, remember
> that hand and then use "hand shiftPressed". Unfortunately, this requires
> the users of TransferMorph to be fixed so that they pass a valid hand in
> the drag process since TransferMorph itself can't easily figure out
> which hand is responsible.
>
> Cheers,
>   - Andreas
>
>> - Bert -
>>
>> On 22.12.2008, at 00:12, karl ramberg wrote:
>>
>>> So maybe the TransferMorph>>step should have a 'self  delete' if owner
>>> is not a hand morph? Or is there cases where transferMorphs live by
>>> them self ?
>>>
>>> Karl
>>>
>>> On 12/21/08, Bert Freudenberg <[hidden email]> wrote:
>>>>
>>>> On 21.12.2008, at 21:06, Julian Fitzell wrote:
>>>>
>>>>> On Sun, Dec 21, 2008 at 8:38 PM, Andreas Raab <[hidden email]>
>>>>> wrote:
>>>>>> Julian Fitzell wrote:
>>>>>>>
>>>>>>> Did anybody ever figure out what the heck is causing this? It's
>>>>>>> driving me nuts!!
>>>>>>
>>>>>> It's users of Sensor>>mouseButtons, Sensor>>shiftPressed etc. The
>>>>>> main
>>>>>> suspect in this regard is TransferMorph which does this:
>>>>>>
>>>>>> TransferMorph>>step
>>>>>>      self shouldCopy: Sensor shiftPressed.
>>>>>>      self updateCopyIcon
>>>>>>
>>>>>> A lingering TransforMorph (which can happen after DnD errors) will
>>>>>> happily
>>>>>> eat all your events.
>>>>>
>>>>> Thank you, thank you, thank you. This fixed it:
>>>>>
>>>>> TransferMorph allInstances do: [:ea | ea delete]
>>>>>
>>>>> (there was a lingering one - it had an omnibrowser method node as a
>>>>> passenger)
>>>>>
>>>>> Not sure why this is happening so much to me right now but at least I
>>>>> have a fix.
>>>>
>>>>
>>>> Oh great! We have encountered this from time to time but never got
>>>> down to the cause. Thanks Andreas!
>>>>
>>>> - Bert -
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: losing mouse clicks

Göran Krampe
In reply to this post by Bert Freudenberg
...and while on the "subject":

When hacking on Blackfoot (my SimpleCGI implementation) I have noticed
that banging on Blackfoot through Nginx (a web server) using ab (apache
benchmark) the image seem to inevitably (but definitely not immediately)
end up in a state where it does not take mouse/keyboard events nor
redraws when being resized. However - it still cranks out SCGI responses
like before. So it doesn't seem to happen easily, but when pushing it
with thousands of requests it eventually happens.

So somehow the UI died but Socket and the listening Process etc works
just fine.

I presume this can happen using KomHttpServer or whatever, intuitively
it can't be something Blackfoot does - anyone seen it?

Using... oh darn, the VM is way old :) It is a 3.9-8, and a 3.9 7067
image. I will see if it still appears with the newest VM/image combo.

regards, Göran


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: losing mouse clicks

keith1y
Göran Krampe wrote:

> ...and while on the "subject":
>
> When hacking on Blackfoot (my SimpleCGI implementation) I have noticed
> that banging on Blackfoot through Nginx (a web server) using ab
> (apache benchmark) the image seem to inevitably (but definitely not
> immediately) end up in a state where it does not take mouse/keyboard
> events nor redraws when being resized. However - it still cranks out
> SCGI responses like before. So it doesn't seem to happen easily, but
> when pushing it with thousands of requests it eventually happens.
>
> So somehow the UI died but Socket and the listening Process etc works
> just fine.
>
> I presume this can happen using KomHttpServer or whatever, intuitively
> it can't be something Blackfoot does - anyone seen it?
>
> Using... oh darn, the VM is way old :) It is a 3.9-8, and a 3.9 7067
> image. I will see if it still appears with the newest VM/image combo.
>
> regards, Göran
It looks like you are hitting one of those old image freezing problems.
Which I fixed in the old days by going back to a 3.7.7 vm. More recently
we had a load of fixes to Semaphores and friends which (I think) made it
into 3.10

Keith


Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: losing mouse clicks

Andreas.Raab
In reply to this post by Göran Krampe
Hi Göran -

The first thing to check is what priorities these various processes are
at. I would guess that if you keep hitting your listener loop hard
enough it would at some point consume all available CPU. And if any of
the processes keeps eating CPU at high priority your UI will become
unresponsive at some point (note that the effect can be hidden - for
example if you have a gazillion Delays they could conceivably block the
timer event handler adding/removing Delays from the lists etc).

A good thing to do is when the whole UI is unresponsive is to ask the VM
what it is currently doing by calling printCallStack or printAllStacks.
In our server VMs -USR1 is hooked up to do this but you can run the VM
under gdb (or attach gdb --pid when it's in this state) and ask gdb to
call printCallStacks(). Do this a couple of times to give the result a
bit more statistical validity and at the end you can be pretty sure
that's where it is spending time.

Cheers,
   - Andreas

Göran Krampe wrote:

> ...and while on the "subject":
>
> When hacking on Blackfoot (my SimpleCGI implementation) I have noticed
> that banging on Blackfoot through Nginx (a web server) using ab (apache
> benchmark) the image seem to inevitably (but definitely not immediately)
> end up in a state where it does not take mouse/keyboard events nor
> redraws when being resized. However - it still cranks out SCGI responses
> like before. So it doesn't seem to happen easily, but when pushing it
> with thousands of requests it eventually happens.
>
> So somehow the UI died but Socket and the listening Process etc works
> just fine.
>
> I presume this can happen using KomHttpServer or whatever, intuitively
> it can't be something Blackfoot does - anyone seen it?
>
> Using... oh darn, the VM is way old :) It is a 3.9-8, and a 3.9 7067
> image. I will see if it still appears with the newest VM/image combo.
>
> regards, Göran
>
>
>