c2c-oerpscenario team mailing list archive

[xrg <xrg@xxxxxxxxx>]

On Wednesday 09 March 2011, you wrote:
> Hello XRG,
> 
> Yes it's good that the GTK client warn's the developer about the duplicate
> IDS and to fix the search method defined. I tried the fix with just a
> simple example I overridden the search method of Sale_order and returned
> the ID'S as [IDS] + [IDS] and there was no change. the duplicated Ids were
> shown by the client.
> 
> BTW your FIX will not allow to do so because you are comparing the Instance
> of 'Model Record' i.e by writing "if l in self.lst:" here 'l' is the
> instance. So this will always be False because each search will rebuild
> the Model Record with the IDS returned in-spite of their duplication. I
> think you should compare them through their ID.
> 
> 
> Let me know If I am missing something.
> 
At my case, the problem (OOM) occured when I had those IDs listed in a 
_groupped_ list and actually when the duplicates were next to each other like
 res = obj.search()
 res => [ 45, 67, 140, 140, 153]

the bug is that (perhaps due to widget/model/group.py:416, 
widget/view/list.py:196) the exact same ModelRecord object appears twice in 
the list (list_record.lst ). Then, at list.py:315:on_iter_next(2) returns the 
lst[3] element. But, that, is equivalent to lst[2], and so on_iter_next(3) 
will again return lst[3] == lst[2]. And that's an endless loop.

If, as you say, we insert different ModelRecord objects of the same record ids, 
the problem won't occur. Still, listing them many times at the same list is a 
logical error for the user (imagine selecting them both and applying an 
action).

My patch, hopefully, fixed the extreme case (of the groupped list) in a way 
with least side-effects.

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/728275

Title:
  view/list: Fix handling of duplicate IDs from search()

Status in OpenERP GTK Client:
  Confirmed

Bug description:
  A /broken/ model (report.membership) at the server happened to return
  duplicate ids of records (using a badly migrated dataset, too). This
  propagated to the Gtk client, which inserted the ids at duplicate
  positions of the list view. When iterating over them, the client was
  trapped into an OOM, which is critical and DoSes the host desktop.

  The server should never have done that, agreed. But, the network principle
  says "send clean, accept garbage", so we'd better not die if such data
  ever come again.
  Gently logging the case was the way to go. If we raise an exception (tried
  that), the Gtk framework will come back asking for the list item again,
  which ends up in an ugly full-load (but not lethal) of the client (and a
  few more calls to the server).