Created attachment 431390 [details]
Attached traceback automatically from anaconda.

Created attachment 431393 [details]
crash screenshot

I've encountered this, when anaconda asked me for disk initialization.
I've switched to tty2 and got network running (ifconfig eth0 up && dhclient eth0), then I've provided bugzilla credentials, but instalation continued until partitiong.
No bug was submitted in bugzilla at this point.
I selected Use entire drive option. Partitions started to be formatted and when root partition was formatting, window telling me that bug was submitted to bugzilla popped up.
I clicked OK and another traceback was shown (with similar error). I've tried to send it to bugzilla, but when I provided bugzilla credentials, the X went down and I saw screen provided in attachment.

Thanks for filing this bug report.

Can you clarify exactly which tree you saw this with?

Are you able to reproduce this issue?  It would be very useful if you could obtain a coredump from anaconda (I am attempting to track down a simple way of doing this)

Transcribing the error message from the screenshot:
python: Modules/gcmodule.c:277: visit_decref: Assertion `gc->gc.gc_refs != 0' failed.

Corresponding line from the source code is:
/* A traversal callback for subtract_refs. */
static int
visit_decref(PyObject *op, void *data)
{
[snip]
		assert(gc->gc.gc_refs != 0); /* else refcount was too small */
[snip]
}

This happens during the garbage collector if a Python object has been decref-ed too many times: we've seeing if an object is still live by accounting for all of the references that other objects hold to it, but ob_refcnt is lower than the number of such references.  This suggests a reference-counting bug somewhere in the code of either python or an extension module.

Need a coredump to figure out which object it was, and thus where the buggy code is.

FWIW, I've filed http://bugs.python.org/issue9263 upstream with a patch to python that may make it easier to track down this kind of bug

It was RHEL6.0-20100707.4 x86_64 Server with:
anaconda-13.21.56-1.el6
python-2.6.2-11.el6

It happens quiet randomly. I'll try to reproduce it once I have debug image.

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

I've just hit this bug on RHEL6.0-20100722.0 x86_64 Server (inside KVM again) and anaconda freezes when disks are being detected. But I'm able to execute commands on tty2.

Has this only ever happened inside KVM?  If so, this could be another symptom of bug 607650.

I'm not sure, I've updated kernel yesterday and haven't tried it yet.
It happens quite randomly so it may take time to reproduce this.

Ok, I haven't hit this bug with new kernel, so it looks like it's duplicate.

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