« Return to Thread: bogus timer id in wxTimerProc
Re: Re: bogus timer id in wxTimerProc
by Robin Dunn
::
Rate this Message:
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
> 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
« Return to Thread: bogus timer id in wxTimerProc
| Free embeddable forum powered by Nabble | Forum Help |
