Comment #1 on issue 286 by jas...@google.com: Inconsistency with repeated fields using C++ protobufs
http://code.google.com/p/protobuf/issues/detail?id=286

Thanks for reporting this.

I believe what's happening here is some problems with Python refcounting and the fact that the C++ implementation reuses submessages to avoid reallocations.

keepitems = [r for r in p.repeated if r.name != 'B']
- this line ends up copying python objects wrapping the pointers to C++ objects stored in the repeated field of messages

del p.repeated[:]
- this line causes the C++ code to clear the repeated field. Under the hood, the C++ objects are not deleted, but Clear()'ed. The implementation is unaware that there are still python objects wrapping the C++ objects.

p.repeated.extend(keepitems)
- causes RepeatedPtrField::Add() to be called, which now returns the same instances as were previously used.

In test1.py, keepitems contains a python object wrapping what's supposed to be the 'A' object. When extend() is called, the same underlying C++ object is used, causing the crash, so when it tries to copy the data over using MergeFrom(), the crash is triggered.

In test2.py, keepitems contains a python object wrapping what's supposed to be the 'B' object, except that C++ message has been cleared. When extend() is called, the C++ object originally used to store the 'A' object is returned. The MergeFrom() call succeeds, but since the message has been cleared, you get an empty object.

I'm not familiar enough with Python and C extensions to propose a fix, or even to know how the pure Python implementation handles this. Jisi, any ideas on that or even just an owner for this bug?

--
You received this message because you are subscribed to the Google Groups "Protocol 
Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Reply via email to