After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 465854 - RuntimeError when performing role_accel_label test (new pyatspi).
RuntimeError when performing role_accel_label test (new pyatspi).
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: general
unspecified
Other Linux
: Normal normal
: 2.22.0
Assigned To: Eitan Isaacson
Orca Maintainers
Depends on:
Blocks: 448848
 
 
Reported: 2007-08-12 03:46 UTC by Eitan Isaacson
Modified: 2008-07-22 19:32 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Fix (1.53 KB, patch)
2007-08-16 16:15 UTC, Eitan Isaacson 		none Details | Review

Description Eitan Isaacson 2007-08-12 03:46:39 UTC 
With a patched version of orca from bug 448848.

When I run test/keystrokes/gtk-demo/role_accel_label.py I get the following exception:

Traceback (most recent call last):

+ Trace 154564

  • File "/opt/gnome2/lib/python2.5/site-packages/pyatspi/registry.py", line 274 in notifyEvent 
    self.registry.handleEvent(ev)
  • File "/opt/gnome2/lib/python2.5/site-packages/pyatspi/registry.py", line 602 in handleEvent 
    self._dispatchEvent(event)
  • File "/opt/gnome2/lib/python2.5/site-packages/pyatspi/registry.py", line 618 in _dispatchEvent 
    clients = self.clients[et.name]
RuntimeError: maximum recursion depth exceeded in cmp 

The funny thing is that any string comparison will trigger that. So if I insert "print 'elton' == 'john'" at registry.py:618, A similar exception is raised.
Comment 1 Eitan Isaacson 2007-08-16 00:28:13 UTC 
This has stumped me for a while.
It turns out that there was more then one reason event type comparison wasn't working in FocusTrackingPresenter._enqueueEvent(). This didn't allow object:property-change:accessible-parent events to be filtered out, and thus caused a stack overflow in synchronous mode. Does all that make sense? not %100. Did the back trace that orca provided make sense? No, and it was indeterminate, changing with one computer state to another. Will I further investigate all these anomalies? Not now :)
Comment 2 Willie Walker 2007-08-16 00:46:25 UTC 
(In reply to comment #1)
> This has stumped me for a while.
> It turns out that there was more then one reason event type comparison wasn't
> working in FocusTrackingPresenter._enqueueEvent(). This didn't allow
> object:property-change:accessible-parent events to be filtered out, and thus
> caused a stack overflow in synchronous mode. Does all that make sense? not
> %100. Did the back trace that orca provided make sense? No, and it was
> indeterminate, changing with one computer state to another. Will I further
> investigate all these anomalies? Not now :)

Strange.  So, how did you fix it?
Comment 3 Eitan Isaacson 2007-08-16 01:30:53 UTC 
> Strange.  So, how did you fix it?
> 

I fixed the event type comparison so object:property-change:accessible-parent doesn't hose it all.
Comment 4 Eitan Isaacson 2007-08-16 16:15:41 UTC 
Created attachment 93786 [details] [review]
Fix

Just added this for the sake of the scribes.