Autopilot-gtk must not use memory addresses as object ids

Bug #1212926 reported by Thomi Richards
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

The fact that autopilot-gtk is using object memory address locations as object ids is causing problems with server-side parameter matching, where values outside MININT <-> MAXINT overflow the xpathselect rule.

Related branches

Revision history for this message
Martin Pitt (pitti) wrote :

I don't understand that -- refreshing properties of a GObject doesn't change the address of the GObject itself. That would only happen if you destroy e. g. a button and re-create it?

Revision history for this message
Martin Pitt (pitti) wrote :

Ah, I understand now. AFAICS, the easiest option is to just use the
lower 32 bits. This ought to work in practice as the heap is in a
single virtual segment anyway, so as long as we don't create many
hundred million widgets (which we couldn't handle anyway, FWIW) there
should be no collisions.

The alternative would be to use an increasing number like in -Qt.
When I previously wrote "there are no dynamic properties" I forgot
about qdata, which provides something like that. They are not type
save or introspectable, but that isn't necessary. Something like

  GQuark OBJ_ID = g_quark_from_static_string("AUTOPILOT_OBJECT_ID");
  static guint32 cur_obj_id = 1;

in the ap initialization, and then

  g_object_set_qdata (my_widget, OBJ_ID, (gpointer) cur_obj_id++);


  guint32 id = (guint32) g_object_get_qdata (my_widget, OBJ_ID);

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:autopilot-gtk at revision 53, scheduled for release in autopilot-gtk, milestone Unknown

Changed in autopilot-gtk:
status: Triaged → Fix Committed
Martin Pitt (pitti)
Changed in autopilot-gtk:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers