Bug 246044

Created attachment 158085 [details]
results of 'rpm -vv -Uvh --force vim-common-7.1.12-1.fc8.x86_64.rpm'

Created attachment 158086 [details]
results of 'rpm -vv -e asymptote'

Opps!  Forgot to mention.  All explicit rpm operations were done when
all rpm packages were already updated to 4.4.2.1-0.2.rc1.  I am not
sure if 'yum update' used that when it got stuck but all releated
rpm packages cleanups happened before a cleanup for vim-common was
attempted. A cleanup for 'emacs-common', which also shows up in
asymptote triggers and accidentally was in the same update transaction,
was already finished before ab update tied itself in a knot.

Am seeing this as well - vim-common-7.1.12-1.fc8.x86_64.rpm causes both yum and
rpm indigestion (found it first when 'yum update' against rawhide updated 83
packages and then cleaned up only 70 before wedging).  I think asymptote is a
red herring, or "just the trigger", as it's not installed on my machine at all.

Also, I saw the same problem intermittently with other RPMS as well - scim-libs,
popt and krb5-libs RPMs at least.  It seemed to be *very* order-dependent. If I
did 'rpm -Uvh --force [s-x]*.rpm' it would hang consistently on scim-libs, but
then when I did 'rpm -Uvh --force s*' followed by '--force x*' in 2 seperate
commands, it worked without complaint.

Here's the tail end of 'rpm -Uvh --force -vv vim-common':

++ sort
++ head -n 1
++ sed -e 's/[0-9]*://'
++ sed -e 's/\.[0-9]*$//'
++ sed -e 's/\.//'
+ VIMVEROLD=71
++ rpm -q '--qf=%{epoch}:%{version}\n' vim-common
++ sort
++ tail -n 1
++ sed -e 's/[0-9]*://'
++ sed -e 's/\.[0-9]*$//'
++ sed -e 's/\.//'
+ VIMVERNEW=71
+ '[' 1 = 1 ']'
+ rm -f /usr/share/vim/vim71/syntax/syslog-ng.vim
+ '[' -d /usr/share/vim/vim71/syntax ']'
+ cd /usr/share/vim/vim71/syntax
+ ln -sf ../../../syslog-ng/syslog-ng.vim .
D:     erase: waitpid(23361) rc 23361 status 0 secs 0.126
D:   --- h#    1875 vim-common-7.1.2-1.fc8

And then we're waiting for something to happen:

# ps lax | grep rpm
4     0 23330 18552  20   0 130196 27532 futex_ S+   pts/1      0:03 rpm -Uvh
--force -vv vim-common-7.1.12-1.fc8.x86_64.rpm

No idea what that futex is attached to, though.  If need be, I can strace it if
that would help.

OK.. I'll bite.   Looking back at Michal's comments, I got brave and tried 'rpm
-Uvh --force --noscripts vim-common*'.  And that worked.  Unclear why adding
--noscripts makes it work when 'rpm -q --scripts vim-common' says there *aren't*
any scripts for the RPM.....

>  I think asymptote is a red herring
Quite possible and that is why I wrote "apparently".  This was
just one observation and in my particular case removing
asymptote got things "unstuck".  Also a quick peek on those
triggers did not reveal any obvious "smoking gun".

Something funny in a database?  Order sensitivity as observed
by Valdis would point in this direction.

Ok, something's busted, I can reproduce reasonably reliably here.

Now to figure out what it is...

--notriggers appears to be enough to clear the stuck erase, and here's the
smoking gun:

[pmatilai@localhost ~]$ rpm -q --triggers asymptote|grep rpm
VIMVERNEW=`rpm -q --qf='%{epoch}:%{version}\n' vim-common | sort | tail -n 1 |
sed -e 's/[0-9]*://' | sed -e 's/\.[0-9]*$//' | sed -e 's/\.//'`
VIMVEROLD=`rpm -q --qf='%{epoch}:%{version}\n' vim-common | sort | head -n 1 |
sed -e 's/[0-9]*://' | sed -e 's/\.[0-9]*$//' | sed -e 's/\.//'`
VIMVEROLD=`rpm -q --qf='%{epoch}:%{version}\n' vim-common | sort | head -n 1 |
sed -e 's/[0-9]*://' | sed -e 's/\.[0-9]*$//' | sed -e 's/\.//'`
VIMVERNEW=`rpm -q --qf='%{epoch}:%{version}\n' vim-common | sort | tail -n 1 |
sed -e 's/[0-9]*://' | sed -e 's/\.[0-9]*$//' | sed -e 's/\.//'

After muchos headscratching and bisecting and throwing away invalid test
results, it turned out to me a seemingly unrelated change which caused the query
within the trigger to leave a db iterator unfreed which then causes the lockup
when running from within a transaction. Fun...

Fixed in rpm.org and should be in tomorrows rawhide (4.4.2.1-0.3.rc1)

I also have the same kind of vim-common triggers in the syslog-ng package.

The vim-common triggers are rather nasty as they have to invoke the rpm command
to    find the vim version being removed/installed/updated  (the vim version is
hardcoded in the shared directories - eg: /usr/share/vim/vim70/).

jpo

I am not sure if that would help in the problem but the quoted
code from asymptote triggers can be simplified somewhat like
that:

   set_vversions () {
      VIMVEROLD="$2"
      VIMVERNEW="$4"
   }
   set_vversions `rpm -q --qf='%{epoch} %{version}\n' vim-common \
     | sort | sed -e 's/\.//' -e 's/\..*$//'`

At least a number of external processes there will be cut down.

... and, as a matter of fact, 'sort' in comment #10 should be
'sort -n'.

The sorts and such are irrelevant to this bug, the bad juju is in calling rpm
from within rpm. It's supposed to work, but it's not a very good idea anyhow for
various reasons.

That said, I'm glad this bug was found now instead of after 4.4.2.1 final release :)

> The sorts and such are irrelevant to this bug ...
That is clear.  Only once you started to talk about "smoking
gun" in comment #8 a suggestion was that maybe simpler
scripts/triggers would make an rpm life easier.

OTOH if that would be too plush then maybe the bug would
hide better. :-)

*** Bug 246127 has been marked as a duplicate of this bug. ***

Hi,

A new build of asymptote will be pushed into the development repository in a
couple of hours (the {emacs,xemacs,vim}-common triggers are still all there).

jpo

What asymptote triggers are doing is "bad", but the bug was in rpm.
rpm-4.4.2.1-0.3.rc1 has now found it's way to rawhide, closing.