1:52 a.m.
On repeated exposure events in the Cygwin build I get an assertion
failure in mswindows_dequeue_dispatch_event. I've never looked at
this code before so there is little chance I could resolve the issue
by the deadline for the next beta. If no one else can get a quick
handle on the problem I will look more closely fore the following
beta. I found it easy to reproduce the problem in gnus by simply
getting into a newsgroup and repeatedly covering part of the Xemacs
frame and then minimizing the covering window.
9:47 a.m.
At 08:52 PM 3/10/99 -0500, David Bush wrote:
On repeated exposure events in the Cygwin build I get an assertion
failure in mswindows_dequeue_dispatch_event. I've never looked at
this code before so there is little chance I could resolve the issue
by the deadline for the next beta. If no one else can get a quick
handle on the problem I will look more closely fore the following
beta. I found it easy to reproduce the problem in gnus by simply
getting into a newsgroup and repeatedly covering part of the Xemacs
frame and then minimizing the covering window.
This bug has been around for ever - if you can get a handle on it that
would be fantastic.
andy
12:46 p.m.
Andy Piper wrote:
At 08:52 PM 3/10/99 -0500, David Bush wrote:
>On repeated exposure events in the Cygwin build I get an assertion
>failure in mswindows_dequeue_dispatch_event. I've never looked at
>this code before so there is little chance I could resolve the issue
>by the deadline for the next beta. If no one else can get a quick
>handle on the problem I will look more closely fore the following
>beta. I found it easy to reproduce the problem in gnus by simply
>getting into a newsgroup and repeatedly covering part of the Xemacs
>frame and then minimizing the covering window.
This bug has been around for ever - if you can get a handle on it that
would be fantastic.
Is this cygwin only, or do people see this on native mswindows too?
Jonathan.
--
Jonathan Harris | jhar(a)tardis.ed.ac.uk
London, England | Jonathan.Harris(a)symbian.com
3:48 p.m.
At 12:46 PM 3/11/99 +0000, Jonathan Harris wrote:
Andy Piper wrote:
>
> At 08:52 PM 3/10/99 -0500, David Bush wrote:
> >On repeated exposure events in the Cygwin build I get an assertion
> >failure in mswindows_dequeue_dispatch_event. I've never looked at
> >this code before so there is little chance I could resolve the issue
> >by the deadline for the next beta. If no one else can get a quick
> >handle on the problem I will look more closely fore the following
> >beta. I found it easy to reproduce the problem in gnus by simply
> >getting into a newsgroup and repeatedly covering part of the Xemacs
> >frame and then minimizing the covering window.
>
> This bug has been around for ever - if you can get a handle on it that
> would be fantastic.
Is this cygwin only, or do people see this on native mswindows too?
I haven't seen any reports from native users. I used to get it a lot more
commonly than I do now, so I don't know what has changed. I wonder if it
has anything to do with the process code given that David gets it when
using gnus. If it is then its probably cygwin only.
Jonathan you know the event code better than me - to me the assertion seems
a little OTT, could we maybe make the failure slightly less brittle and
discard events that we don't think should be there?
andy
7:53 p.m.
Andy Piper wrote:
>> At 08:52 PM 3/10/99 -0500, David Bush wrote:
>> >On repeated exposure events in the Cygwin build I get an assertion
>> >failure in mswindows_dequeue_dispatch_event. I've never looked at
>> >this code before so there is little chance I could resolve the issue
>> >by the deadline for the next beta.
[snip]
Jonathan you know the event code better than me - to me the assertion seems
a little OTT, could we maybe make the failure slightly less brittle and
discard events that we don't think should be there?
My knowledge is a little rusty, but I'm pretty sure that the assert is
good. Just from looking at the code this looks potentially suspect in
mswindows_need_event():
active = select (MAXDESC, &temp_mask, 0, 0, pointer_to_this);
if (active == 0)
{
return; /* timeout */
}
and I notice that in the HAVE_MSG_SELECT version of the
mswindows_need_event() code the call to MsgWaitForMultipleObjects() is
lacking the assert that is present in the non-HAVE_MSG_SELECT version:
assert ((!badly_p && active == WAIT_TIMEOUT) ||
(active >= WAIT_OBJECT_0 &&
active <= WAIT_OBJECT_0 + mswindows_waitable_count));
mswindows_need_event(1) is called by emacs_mswindows_next_event() which
_must_ return an event, so mswindows_need_event(1) must not return
without having put an event in one of the two queues. The real question
appears to be: why is mswindows_need_event(1) timing out? I would
suggest that adding asserts after the select() and
MsgWaitForMultipleObjects() calls in the HAVE_MSG_SELECT version of
mswindows_need_event() would help narrow down the problem.
We can maybe mask the problem by doing something like the following, but
I would be uncomfortable not knowing why we have to mask the problem:
static void
emacs_mswindows_next_event (struct Lisp_Event *emacs_event)
{
Lisp_Object event, event2;
while (NILP (mswindows_u_dispatch_event_queue) &&
NILP (mswindows_s_dispatch_event_queue))
mswindows_need_event (1);
event = mswindows_dequeue_dispatch_event (...
Jonathan.
--
Jonathan Harris | jhar(a)tardis.ed.ac.uk
London, England | Jonathan.Harris(a)symbian.com
11:06 p.m.
>>>> Jonathan Harris <jhar(a)tardis.ed.ac.uk> writes:
Andy Piper wrote:
>
> >> At 08:52 PM 3/10/99 -0500, David Bush wrote:
> >> >On repeated exposure events in the Cygwin build I get an assertion
> >> >failure in mswindows_dequeue_dispatch_event. I've never looked at
> >> >this code before so there is little chance I could resolve the issue
> >> >by the deadline for the next beta.
Jonathan> [snip]
>
> Jonathan you know the event code better than me - to me the
> assertion seems a little OTT, could we maybe make the failure
> slightly less brittle and discard events that we don't think
> should be there?
Jonathan> My knowledge is a little rusty, but I'm pretty sure that
Jonathan> the assert is good. Just from looking at the code this
Jonathan> looks potentially suspect in mswindows_need_event():
There also seems to be a mismatch between the call to
mswindows_dequeue_dispatch_event in emacs_mswindows_next_event
and the actual function. IT is being called with the argument
!NILP(mswindows_u_dispatch_event_queue) but does not have any
arguments. This suggests that there was a change of direction that
wasn't fully realized. I spend some time in the CVS history searching
for enlightenment.
david
6:42 p.m.
At 06:06 PM 3/12/99 -0500, David Bush wrote:
There also seems to be a mismatch between the call to
mswindows_dequeue_dispatch_event in emacs_mswindows_next_event
and the actual function. IT is being called with the argument
!NILP(mswindows_u_dispatch_event_queue) but does not have any
arguments. This suggests that there was a change of direction that
wasn't fully realized. I spend some time in the CVS history searching
for enlightenment.
I've deleted the argument and added an assert to the timeout case. If this
asserts then it means there is a bug in the cygwin implementation of
assert, which would explain a lot.
andy
10:25 a.m.
Andy Piper writes:
At 08:52 PM 3/10/99 -0500, David Bush wrote:
>On repeated exposure events in the Cygwin build I get an assertion
>failure in mswindows_dequeue_dispatch_event. I've never looked at
>this code before so there is little chance I could resolve the issue
>by the deadline for the next beta. If no one else can get a quick
>handle on the problem I will look more closely fore the following
>beta. I found it easy to reproduce the problem in gnus by simply
>getting into a newsgroup and repeatedly covering part of the Xemacs
>frame and then minimizing the covering window.
This bug has been around for ever - if you can get a handle on it that
would be fantastic.
andy
Its just bitten me _again_. You'd be my hero too...
- Phil
9090
days inactive
9171
days old
7 comments
4 participants
participants (4)
-
Andy Piper -
David Bush -
Jonathan Harris -
Philip Aston