Comment 7 for bug 102792

Further details on reproducing: I've reproduced this on Intrepid, Jaunty and Karmic, all from amd64 livecds in virtualbox (and also one Jaunty on my desktop):

0. back up /etc/apt/sources.list - better :-) than :'-(
1. boot up
2. alt-f2 -> Konsole
3. kdesudo software-properties-kde
4. go to second tab (third-party/other software)
5. add a bunch of sources (they don't have to be real): click the add button, enter e.g. 'deb http://first distro main'. repeat about 10 times so that the list is well populated.
6. click on one of the checkboxes repeatedly in succession. I usually clicked the last one. alternatively, use the keyboard by bringing focus to the list, then pressing end and spacebar a whole lot, which effectively goes to either the first or last entry and toggles them many times.
7. after anywhere between 1-30 seconds of toggle, it crashes. usually quite quickly. I never saw it survive - it always crashed eventually.

As for investigation:

With each toggle, SoftwarePropertiesKDE.on_isv_source_toggled is called as a handler for the itemChanged event. This in turn calls SoftwareProperties.toggle_source_use, which calls set_modified_sourceslist. Experiment results:

1. if the call to set_modified_sourcelist is commented out, it doesn't crash.
2. if the first line of set_modified_sourclist is changed to 'return', it does crash. (huh?)
3. if the call to set_modified_sourcelist is inlined, it doesn't crash. (huh??)
4. if the itemChanged signal is replaced with any other signal, e.g. itemClicked (the other handler can be disabled), everything is fine. (hmmm...)

The above strangeness behaves like a corrupt call stack or corrupt memory, since it seems unrelated to anything that is or isn't actually performed at the time of crash, which implies the corruption probably occurred in a previous event and only manifested in a crash in a later event. Going back to what may have occurred in a previous event's handling, the culprit quickly converges to show_isv_sources, and within it, the tree widget's clear() method.

I tried replacing the clear() call with doing it manually:

while self.userinterface.treeview_sources.topLevelItemCount() > 0:
      self.userinterface.treeview_sources.takeTopLevelItem(0)

And after this change, I could no longer recreate the crash anywhere. However, I have not actually pinpointed the root cause (pyqt? qt?) but qt's clear method implementation does do a bunch of work, sending events, deleting objects, detaching them, and even carries a related warning in the docs... so maybe it's really there.

So, either it's a bug triggered in qt's qtreewidget.clear specifically when called from within an itemChanged handler on a well populated list, or maybe not. It might be some other inconsistency somewhere, and the workaround above might just be shuffling the call stack a bit so that the true bug is hidden, but still lurking.

Since I'm a python/qt/pyqt noob, It would be great if anyone can give further insight on these symptoms or continue the investigation. At the very least, please try recreating the bug and then seeing if the fix indeed solves it for u.

I hope this helps, and isn't all rubbish :-)