update-manager crashed with SIGSEGV in DescriptionList()

StacktraceTop:
 DescriptionList (this=<optimized out>) at ../build/include/apt-pkg/cacheiterators.h:429
 pkgCache::VerIterator::TranslatedDescription (this=0xa6d8744) at pkgcache.cc:921
 VersionGetTranslatedDescription (Self=<apt_pkg.Version at remote 0xa6d8734>) at python/cache.cc:1054
 getset_get ()
 _PyObject_GenericGetAttrWithDict ()

Status changed to 'Confirmed' because the bug affects multiple users.

Are you getting this error every time you run update-manager?
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

Not really. I just tried it again and I was able to get the core-dump 2 times (out of ~5). It looks like (but I'm not sure; just a very simple observation) it happens if there are some updates in the queue.

Alright, I will try it a few times on my test machine while updates are available.
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

Marking back to new due to package reassignment.
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

Status changed to 'Confirmed' because the bug affects multiple users.

@Martin Mrazik (mrazik): when you say you get it 2/5 times, could you please add the exact steps to reproduce?

Hi Michael,

I had this bug when I installed Skype directly from their website and ran the deb file. When I ran the .deb file, the Ubuntu Software Centre would open, I'd hit install and the Software Centre would crash. However! Skype did install, but I could not update or install anything else until I had removed Skype.

I had to uninstall Skype from the terminal as I could not figure out how to remove it from the Software Centre without it crashing.

I tried this procedure at least 4 times with the same results each time. I don't think I am able to reproduce it without following those steps.

Michael - looking at all the duplicates of this bug report a couple of them make reference to using settings in update-manager to change servers and then encountering the crash.

Sorry for not being more helpful:

<mvo> hm, I have a vague idea what might be causing this, but it requires some serious effort to look deeper, one simple workaround would be to always refresh the cache when software-properties was run and returns a exit-state that indicates that something changes

The same workaround should probably be added to software-center

Michael: I'm a little perplexed here, because it looks like update-manager already attempts to do that (it calls self.fillstore which calls self.initCache which calls cache.open and cache._initDepCache). Is it not refreshing the cache hard enough or something?

python-apt's documentation seems to indicate fairly clearly that one must create a new cache object after it's been externally modified, which makes some sense given that it's mmaped. A plausible source of trouble would be cached package objects that point into the old cache.

The traceback indicates (with a bit of imagination) that the crash is within self.store.clear(), which would make sense if update-manager were handling a signal on self.treeview_update in a way that involved references to the old cache. However, the workaround in bug 945536 has meant that the cursor-changed signal is a no-op for the duration of self.store.clear(). I wonder if this has caused this problem no longer to be visible in update-manager?

Thanks for your investigation Colin! It looks like the order of clear(), cache.open() was wrong and the clear might have caused calls to the old no longer valid cache. This should be fixed in trunk now, the order got updated and the store removed from the view before the clear().

All right, let's call this fixed by update-manager 1:0.156.12 then:

  [ Michael Vogt ]
  * UpdateManager/UpdateManager.py:
    - disconnect model and clear store before rebuilding the cache,
      thanks to Colin Watson

We can reopen if more duplicates start showing up.

Based on your comments on IRC, it sounds as though there's nothing to be done in software-center:

14:17 <mvo> cjwatson: just fyi, the cache reopen in s-c is done async in the "transaction-finished" signal, so that could be covered as well