You are correct. Because renderer does not take ownership of the Source() object, its reference count is decremented to 0 after the first line. When the reference count hits 0, the object may be reaped by the garbage collector. However, some garbage collectors (not sure about Python's) use delayed collection to improve performance. That is, they don't reap objects available for reaping immediately, but accumulate them and then will delete them at some point in the future. So, renderer.render() *may* execute correctly and Valgrind *may* detect access to a region of memory that has been deallocated.
To further complicate things, it is possible that the code you posted may * appear* to execute correctly *even if the Source object is deleted.* This could happen if no new memory is allocated on top of where Source was allocated, if a new Source object is allocated in the same memory location that the old Source object was allocated, or if a new object of a different type is allocated that overlaps the old Source object but *just so happens* to have memory values that work for Source. All of these are reasons why debugging dangling pointer problems is so difficult. Valgrind will catch most problems if the application is sufficiently complicated and runs long enough. I'm not sure if Valgrind is sophisticated enough to detect dangling pointers that are not referenced (though I suspect it is not). Nathan On Sat, Jan 14, 2012 at 3:44 PM, S. Champailler <schampail...@skynet.be>wrote: > After a bit of reading, I still don't get this. In the doc, I see that his > code is wrong : > > renderer.setModel(Source()) > renderer.render() > > because the Source() object will be destroyed too soon. That makes sense. > > What I don't get is "how wrong" it is. That is, if the Python Source() > object is destroyed by Python, then does it mean that the reference that is > still present in the renderer is wrong (i.e. it has a pointer to some > memory that was freed and that may blow up as soon as renderer tries to > reference that ememory) ? > I don't see any other explanation, but I want to be sure. If it's because > of that then is there somebody who has some experience in debugging that ? > I've set up valgrind but I'm not sure it will bring in systematic result. > After all, if "renderer" never uses the dangling pointer, then valgrind > will never see anything wrong... > > Am I right (this would save me some frustration :-)) > > Stefan > > > > > > Well, > > > > Not that I have figured out how to fix my code, but I did find out the > documentation that explains that in *great* details (and in a rather clear > way). It's there for those who are still looking for : > > > > pyside/shiboken/doc/ownership.rst > > > > I'm a little bit ashamed of not finding this earlier > > > > stF > > > > > > On Mon, Jan 09, 2012 at 10:36:32PM +0100, S. Champailler wrote: > > > Dear mailing list, > > > > > > In my python code, I usually create QStandardItem with some data, but > now I realize it may be plain wrong : > > > > > > > > > def make_simple_model(my_data) > > > model = QtGui.QStandardItemModel(1, 1) > > > > > > item = QtGui.QStandardItem() > > > item.setData(my_data, Qt.UserRole) > > > model.setItem(0, 0, item) # Model takes ownership of the Item (if I > understand Qt's doc well) > > > > > > return model > > > > > > my_data = ... # some kind of Python object > > > model = make_simple_model(my_data) > > > > > > # After this, Python has lost track of my data > > > my_data = None > > > > > > # This one is correct, because model is still tracked by Python and > the item is owned by the model > > > item = model.item(0,0) > > > > > > # But this is dangerous (because the data has been lost) > > > item.data( Qt.UserRole) > > > > > > > > > > > > If I got the "PySide pitfalls" page well, this code is wrong : my_data > got lost (last line of the code) and therefore, the QStandardItem UserRole > data is a dangling p\ > > > ointer... > > > > > > Is my interpretation correct ? If so, I'd be happy to add this to the > "pitfalls" page. Although that page does explain the issue, somehow, I > thought this code was cor\ > > > rect until now (it worked thousands of times) => maybe other > developpers may have the same misunderstanding. > > > > > > Thx, > > > > > > Stefan > > > > > > > > > > > > _______________________________________________ > > > PySide mailing list > > > PySide@lists.pyside.org > > > http://lists.pyside.org/listinfo/pyside > > _______________________________________________ > > PySide mailing list > > PySide@lists.pyside.org > > http://lists.pyside.org/listinfo/pyside > _______________________________________________ > PySide mailing list > PySide@lists.pyside.org > http://lists.pyside.org/listinfo/pyside >
_______________________________________________ PySide mailing list PySide@lists.pyside.org http://lists.pyside.org/listinfo/pyside
