[NBLUG/talk] yum freaked out

syn hex at neg9.org
Tue May 12 10:04:06 PDT 2009


On Tue, 12 May 2009 08:41:32 -0700
Lincoln Peters <anfrind at gmail.com> wrote:

> On Mon, May 11, 2009 at 6:09 PM,  <gandalf at sonic.net> wrote:
> > Thank you very much the yum clean all did it. It just worked after
> > that. It was such a weird looking error I got scared. Thank you so
> > much.
> 
> It looks like a Python traceback to me, which is something you should
> almost never see in a production application.  I'd say that unless you
> recompiled yum or did something similarly drastic, it looks very much
> like a bug in yum.  Hopefully they'll be releasing a fixed version
> very soon.
> 
> (Yes, I've been doing quite a bit of Python coding at my job lately.)
> 
> 

Yes, actually, it is a python traceback. yum is written in
python. While it's pretty rare to see tracebacks, it's not entirely
impossible. There are several production python apps that don't
properly support SIGINT and will give a traceback when you ^C the
app (I belive portage still does that). 

And for bonus points....

  File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 413, in _packageByKey
    po = self.pc(repo, cur.fetchone())
  File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 68, in __init__
    self._read_db_obj(db_obj)
  File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 94, in _read_db_obj
    setattr(self, item, _share_data(db_obj[item]))
TypeError: unsubscriptable object

Since this is python2.4 the error reporting isn't quite as good as
2.5, but if you have 2.4 you can get the same error by trying to use a
None object as a list or a dict.

>>> None[1]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unsubscriptable object

So I'm going to guess that self.pc is called with two arguments, repo
and db_obj. When cur.fetchone() has no results it returns None (iirc),
so instead of a dict or list a None gets passed into pc._read_db_obj
and boom. Now it's been a little while since I've worked with sqlite,
but I believe you can use cur.rowcount to find out if you have any
results before just reading. If you *know* you should have results and
you don't, then yout should raise an error. Even without that a simple
if not db_obj: raise blah_error would improve the situation. This is a
bug in yum because it's a failure of error handling. Otoh, it's not
possible to find every bug before you release... but one should write
code with potential bugs in mind.

-JD



More information about the talk mailing list