bogus timer id in wxTimerProc

wxPython Users
1

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

2

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!

3

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

···

On 9/09/2008 5:36 AM, Robin Dunn wrote:

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

4

James Teh 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.

···

On 9/09/2008 5:36 AM, Robin Dunn wrote:

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