Bug 612853

Created attachment 430573 [details]
File: backtrace

I've tried yum-complete-transaction and yum crashed while installing emacs-common too.

Thanks for filing this bug report.

What is the output of "rpm -qa"?

How reproducible is this?  Are you able to generate a coredump of the crashing process?  A coredump would be most helpful ("ulimit -c unlimited")

Alternatively, are you able to run yum under "valgrind"?  Does this indicate problem areas?
# valgrind /usr/bin/yum

I've been able to reproduce this bug in KVM on Fedora 13 machine with 2.6.33.5-124.fc13.x86_64 kernel with /sys/module/kvm_intel/parameters/ept set to "N".

I've tried this on x86_64 and ppc64 bare metal machines and it was ok.

Created attachment 432249 [details]
Backtrace with debuginfo from coredump ("core.4651")

Backtrace shows free() error "double free or corruption (out)" within libselinux deep inside running an rpm transaction, invoked from the python bindings by yum.

Code in question is line 266 below:

  261             }
  262
  263             if (prev_t2r_trans && strcmp(prev_t2r_trans, trans) == 0) {
  264                     *rawp = strdup(prev_t2r_raw);
  265             } else {
> 266                     free(prev_t2r_trans);
  267                     prev_t2r_trans = NULL;
  268                     free(prev_t2r_raw);
  269                     prev_t2r_raw = NULL;
  270                     if (trans_to_raw_context(trans, rawp))

"prev_t2r_trans" appears to be unavailable directly via coredump, but disassembly suggests it's in %r12, which is:
(gdb) p $r12
$1 = 64886592
(gdb) p (char*)64886592
$2 = 0x3de1740 ""

Defined at /usr/src/debug/libselinux-2.0.94/src/setrans_client.c:30
   30 static __thread security_context_t prev_t2r_trans = NULL;

Only written to via a call to strdup()

Similarities with bug 615102, but I'm not sure if they're duplicates at this stage.

Created attachment 432259 [details]
DSOs mapped in the process

Output from running:
gdb -c core.4651 --eval-command="python print '\n'.join([dso.filename for dso in gdb.objfiles()])" --batch|grep "^/" |sort > dsos.txt

(In reply to comment #7)
> I've been able to reproduce this bug in KVM on Fedora 13 machine with
> 2.6.33.5-124.fc13.x86_64 kernel with /sys/module/kvm_intel/parameters/ept set
> to "N".
> 
> I've tried this on x86_64 and ppc64 bare metal machines and it was ok.    

Pavel: how reproducible is this?  Are you able to reproduce it reliably on KVM guests?  Are you able to reproduce it at all on bare-metal?

CCing pmatilai and dwalsh: see attachment 432249 [details].  The backtrace from the coredump shows heap corruption seen in a call to selinux_trans_to_raw_context deep inside librpm as called by yum from the rpm-python bindings.  Any thoughts?

There could be a number of causes for this:
- I'm not familiar with the "__thread" annotation on variables (see comment #9); perhaps that's not working properly?  (would presumably need to be zeroed for every thread).  (Perhaps it did work, but I'm misreading the coredump).
- could be some kind of heap misuse going on elsewhere within the process.  How much testing under valgrind have, say, the most recent rpm-python bindings had?
- might relate to bug 615102

It happens quite often, but randomly and not always.
I've tried to reproduce it twice now with no success.
From what I observed, when this bug occurs, it is very probable, that it will happen again even after new installation with new disk image. But when it doesn't occur, it's probable that everything will be ok next time too.

As mentioned in comment 7, I'm only able to reproduce it on KVM guest only.

Thanks for the info.

Does it happen just on one specific host?  Could we be seeing a hardware problem?

> From what I observed, when this bug occurs, it is very probable, that it will
> happen again even after new installation with new disk image. But when it
> doesn't occur, it's probable that everything will be ok next time too.
Could this relate to the state of the hypervisor?   Is the clumping of success/failure related to, say, reboots of the hypervisor?

I'm not able to reproduce this bug any more, so I can't tell. Last time I was able to reproduce it was in comment 7. Since that time, I've performed yum update on my system (both kernel and libvirt were updated).
I've tried to reproduce this bug many times with no success.

This may be a duplicate of bug 608710

Given that this only happened on KVM hardware, it looks like it was a duplicate of bug 607650.

*** This bug has been marked as a duplicate of bug 607650 ***