bogus timer id in wxTimerProc

[Mark Guagenti]

I'm curious about what the following error means:
PyAssertionError: C++ assertion "node != TimerMap().end()" failed at
..\..\src\msw\timer.cpp(158) in wxTimerProc(): bogus timer id in
wxTimerProc

>From the little I could learn about this error from searching around
it seems like this might happen if a timer is started from a different
thread.

I'm seeing in this on Windows XP with wxPython  2.8.7.1

Anyone else have any light they could shed on what would generate this
assertion?

Thanks,
--Mark
_______________________________________________
wxpython-users mailing list
wxpython-users@...
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

[Robin Dunn]

Mark Guagenti wrote:

> I'm curious about what the following error means:
> PyAssertionError: C++ assertion "node != TimerMap().end()" failed at
> ..\..\src\msw\timer.cpp(158) in wxTimerProc(): bogus timer id in
> wxTimerProc
>
>>From the little I could learn about this error from searching around
> it seems like this might happen if a timer is started from a different
> thread.
>
> I'm seeing in this on Windows XP with wxPython  2.8.7.1
>
> Anyone else have any light they could shed on what would generate this
> assertion?

Another possibility is that there is a timer event already in the queue
when the timer is destroyed.  When the event is then processed the main
timer WinProc is called and it tries to find info about the timer from
the ID so it can dispatch the wx event, but the id is no longer in the
hash map.


--
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!

_______________________________________________
wxpython-users mailing list
wxpython-users@...
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

[James Teh-2]

On 9/09/2008 5:36 AM, Robin Dunn wrote:
>> PyAssertionError: C++ assertion "node != TimerMap().end()" failed at
>> ..\..\src\msw\timer.cpp(158) in wxTimerProc(): bogus timer id in
>> wxTimerProc
> Another possibility is that there is a timer event already in the queue
> when the timer is destroyed. When the event is then processed the main
> timer WinProc is called and it tries to find info about the timer from
> the ID so it can dispatch the wx event, but the id is no longer in the
> hash map.
This is occurring for me also. I have a repeating timer which is often
reset due to a user action. The use case is a blinking braille cursor.
The interval must be reset every time the cursor moves. Unfortunately,
it seems that there is far too often already a timer event in the queue
when the timer is stopped and restarted.

These errors appear to be harmless, so is there any way to suppress
them? Perhaps this should be filed as a bug against wxWindows, as
reading elsewhere seems to indicate it is only an issue on Windows.

Slightly more concerning is the fact that these timer wx.PyAssertion
errors seem to be raised in very strange places for me, which makes them
extremely difficult to catch. The exception appears to be raised in the
middle of code executed by other timers, which I find extremely odd. To
provide one of several examples:
> Traceback (most recent call last):
>   File "d:\src\nvda\braille\source\core.py", line 147, in Notify
>     IAccessibleHandler.pumpAll()
>   File "d:\src\nvda\braille\source\IAccessibleHandler.py", line 935, in pumpAll
>     winEvents=winEventLimiter.flushEvents()
>   File "d:\src\nvda\braille\source\IAccessibleHandler.py", line 232, in flushEvents
>     for k,v in g.iteritems():
> PyAssertionError: C++ assertion "node != TimerMap().end()" failed at ..\..\src\msw\timer.cpp(158) in wxTimerProc(): bogus timer id in wxTimerProc
Testing reveals that this is not just strange log output; Python
actually *does* raise the exception in the middle of that code.
This would seem to indicate that execution is interrupted by some sort
of Windows callback which processes the timer, but as I understand it,
timers are handled as events, which means they should execute from the
wx main loop. Is this perhaps due to the way wxPython raises exceptions
from its C++ components?

This is quite a big problem for me, as I can't catch these errors and
they are interrupting other code.

Jamie

--
James Teh
Email: jamie@...
WWW: http://www.jantrid.net/
MSN Messenger: jamie@...
Jabber: jteh@...
Yahoo: jcs_teh

_______________________________________________
wxpython-users mailing list
wxpython-users@...
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

[Robin Dunn]

James Teh wrote:

> On 9/09/2008 5:36 AM, Robin Dunn wrote:
>>> PyAssertionError: C++ assertion "node != TimerMap().end()" failed at
>>> ..\..\src\msw\timer.cpp(158) in wxTimerProc(): bogus timer id in
>>> wxTimerProc
>> Another possibility is that there is a timer event already in the queue
>> when the timer is destroyed. When the event is then processed the main
>> timer WinProc is called and it tries to find info about the timer from
>> the ID so it can dispatch the wx event, but the id is no longer in the
>> hash map.
> This is occurring for me also. I have a repeating timer which is often
> reset due to a user action. The use case is a blinking braille cursor.
> The interval must be reset every time the cursor moves. Unfortunately,
> it seems that there is far too often already a timer event in the queue
> when the timer is stopped and restarted.
>
> These errors appear to be harmless, so is there any way to suppress
> them? Perhaps this should be filed as a bug against wxWindows, as
> reading elsewhere seems to indicate it is only an issue on Windows.
>
> Slightly more concerning is the fact that these timer wx.PyAssertion
> errors seem to be raised in very strange places for me, which makes them
> extremely difficult to catch. The exception appears to be raised in the
> middle of code executed by other timers, which I find extremely odd. To
> provide one of several examples:
>> Traceback (most recent call last):
>>   File "d:\src\nvda\braille\source\core.py", line 147, in Notify
>>     IAccessibleHandler.pumpAll()
>>   File "d:\src\nvda\braille\source\IAccessibleHandler.py", line 935,
>> in pumpAll
>>     winEvents=winEventLimiter.flushEvents()
>>   File "d:\src\nvda\braille\source\IAccessibleHandler.py", line 232,
>> in flushEvents
>>     for k,v in g.iteritems():
>> PyAssertionError: C++ assertion "node != TimerMap().end()" failed at
>> ..\..\src\msw\timer.cpp(158) in wxTimerProc(): bogus timer id in
>> wxTimerProc
> Testing reveals that this is not just strange log output; Python
> actually *does* raise the exception in the middle of that code.
> This would seem to indicate that execution is interrupted by some sort
> of Windows callback which processes the timer, but as I understand it,
> timers are handled as events, which means they should execute from the
> wx main loop. Is this perhaps due to the way wxPython raises exceptions
> from its C++ components?

When the C++ assertion happens it is turned into a Python exception, but
if the current execution point is in some other C/C++ code at the time
because the MainLoop is processing events, then the Python exception
doesn't go anywhere until control returns from C to Python, and then the
Python interpreter will notice the exception and start raising it.


> This is quite a big problem for me, as I can't catch these errors and
> they are interrupting other code.

See the docstring for wx.App.SetAssertMode.

--
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!

_______________________________________________
wxpython-users mailing list
wxpython-users@...
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users