Created attachment 254001 [details]
Anaconda generated report

Can you reproduce this reliably?

Has I said, tried it twice.  First time I hit the "upgrade" button with the
mouse. Second time I typed "alt-whatever key was highlighted".  Failed on both
instances with the same error.  Third time I ran in text mode and it worked :-)
On that installation I was doing a hard disk install.  I've since burned a DVD
and will try it on machine at work soon.

Created attachment 257011 [details]
Export of exception report

Comment on attachment 257011 [details]
Export of exception report

Experiencing the same issue, the instant the "Upgrade" option is selected, the
exception occurs.

I was eventually able to run the upgrade by using the upgrade - text mode 
option from a boot CD.

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

I also hit this bug while I was triing to navigate thru keyboard in upgrade
screen. The anaconda error is the same:
anaconda 11.3.0.50 exception report
Traceback (most recent call first):
  File "/usr/lib/anaconda/iw/pixmapRadioButtonGroup_gui.py", line 22, in toggled
    if self.togglecb is not None:
AttributeError: pixmapRadioButtonGroup instance has no attribute 'togglecb'

Local variables in innermost frame:
widget: <gtk.RadioButton object at 0xaab3acc (GtkRadioButton at 0xb486000)>
self: <pixmapRadioButtonGroup_gui.pixmapRadioButtonGroup instance at 0xac0dcac>

I was still able to do upgrade by using mouse (never touch keyboard :).

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

I've seen the same problem too. I have a mouse plugged in, but didn't touch it.
Just tabbed around the Install/Upgrade page to change from the default of
Install to Upgrade. I started the install with 'upgradeany' on the command line, 

I've reproduced, without the 'upgradeany'. It occurred after tab (to select
Install), then down arrow, to move to upgrade. 

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

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

Thats a duplicate, yes, with exception it is reported agains rawhide, not F8..
well this means, this bug will be also in F9... so please switch version to
rawhide then.

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

I can reproduce this 100% on rawhide 2008-04-30

anaconda-11.4.0.79-1.i386.rpm

I don't see how we can ship Fedora 9 without fixing this.

Fedora 8 was shipped with this bug.  Workaround is install/update in text mode.
 Will trip a few people for sure.

Do we know the exact conditions that cause the problem and how many people it is
likely to affect?

http://fedoraproject.org/wiki/QA/ReleaseCriteria says upgrades must work...
unfortunately it doesn't specify whether "text mode is good enough".  Personally
I think this should block the release, but could be argued out of it if I could
understand why this is an unusual occurrence for most people.

Just tried again and I'm still not reproducing this.  And from code inspection,
I still fail to see how this could ever happen.

Is anyone who is seeing it happening to do so in kvm or vmware or the like and
could get a video with istanbul of exactly how they're doing everything.  As I'm
pretty convinced there's something subtly different about the interaction and
it's not something that you're even consciously doing.

tried again today and cannot reproduce... will keep an eye out for it happening
again and try to capture.

moving to F9target blocker

I can reproduce this reliably, using no mouse interactions for any prior screens
just tabbing to Upgrade will cause this crash in 11.4.0.79

What installation media are you using? I tried the boot.iso in VirtualBox with
netinstall, but was not succesfull to trigger that. Are you booting on real HW?

I was able to reproduce it in the past by switching to tty1 and back to the gui
before clicking on the upgrade button, but I still don't see how that could ever
happen.  You can complete upgrades in the graphical interface - people are doing
it all the time.

I can consistently reproduce this if I change tty's to tty1, and back to tty6 at
the upgrade/install screen (as noted by clumens in comment#23).  Which of course
sounds crazy, could there be something sinister lurking (multilib issues, gtk
toolkit issue, kernel)?

This upgrade was initiated using also started using preupgrade (e.g. stage2=
method=).  Not sure if that makes a difference.

Upgrades work just fine here. I actually did trigger this once, but haven't been
able to figure out what I did differently that time.

I believe you can work around this bug by not using the keyboard until *after*
you're past the Upgrade screen.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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

Created attachment 305749 [details]
anadonda dump saved when upgrade button was pressed using Alt-U.

I was able to reproduce this issue consistently, when upgrading from
F8 or F9-preview to F9, on several machines.  Attached please find
saved anaconda dump.

I'll keep this setting in place for the next few days in case you want
me to execute/probe what happened.

I was able to enter python debugger, and got this: (some typo
possible, as I have to type in the screen dump because I could not
copy and paste from the upgrading machine)


Entering debugger...
> /usr/lib/anaconda/iw/pixmapRadioButtonGroup_gui.py(28)toggled()
-> if self.togglecb is not None:
(Pdb) w
  /usr/bin/anaconda(1062)<module>()
->anaconda.intf.run(anaconda)
  /usr/bin/anaconda/gui.py(1231)run()
->self.icw.run( (self.runres)
  /usr/bin/anaconda/gui.py(1482)run()
-> gtk.main()
> /usr/lib/anaconda/iw/pixmapRadioButtonGroup_gui.py(28)toggled()
-> if self.togglecb is not None:
(Pdb) p self
<pixmapRadioButtonGroup_gui.pixmapRadioButtonGroup instance at 0xb76038cc>
(Pdb) p self.togglecb
*** AttributeError: AttributeError("pixmapRadioButtonGroup instance has no
attribute 'togglecb'",)

Follow up to Comment #28:

(Pdb) p self
<pixmapRadioButtonGroup_gui.pixmapRadioButtonGroup instance at 0xb76bd8cc
(Pdb) p self.__dict__
{}
(Pdb) u
> /usr/lib/anaconda/gui.py(1482)run()
-> gtk.main()
(Pdb) p self
<gui.InstallcontrolWindow instance at 0xb76dea2c>
(Pdb) p self.__dict__
{'handle': 19, 'currentWindow': <UpgradeExamineWindow.UpgradeExamineWindow
instance at 0xb76bd98c>, 'mainxml': <glade.XML object at 0xb7b83e64 (PyGladeXML
at 0x968d1c0)>, 'window': <gtk.Window object at 0xb76c2144 (GtkWindow at
0x97e98f8)>, 'installFrame': <gtk.Frame object at 0xb76c24b4 (GtkFrame at
0x97ca8d0)>, 'anaconda': <__main__.Anaconda instance at 0xb7ff9d2c>,
'reloadRcQueued': 0}

Follow up to Comment #29:
(Pdb) p self.window.__dict__
{}

But in InstallControlWindow::run() we have:
    def run (self, runres):
        self.setup_window(runres)
        gtk.main()
and InstallControlWindow::setup_window() has
    def setup_window (self, runres):
        self.window = self.mainxml.get_widget("mainWindow")

Since p self.window.__dict__ is {} at time of exception,
I can only imagine that, either (1) this line
        self.window = self.mainxml.get_widget("mainWindow")
failed, or (2) someone else removes all attributes of 
self.window.

Not sure if this one is a valid test, anyway I tried this in
InstallcontrolWindow:

(Pdb) p self
<gui.InstallcontrolWindow instance at 0xb76dea2c>
(Pdb) self.window = 5       # just to clear it out
(Pdb) p self.window
5
(Pdb) self.window = self.mainxml.get_widget("mainWindow")
(Pdb) p self.window
{}

ie. self.mainxml.get_widget("mainWindow") returns an empty obj in this
run.

At examine_gui.py:82, we have
    def getScreen (self, anaconda):
	r = self.createUpgradeOption()  # line 96
where r is an local variable, not a class 
variable (assigned to self.xxx).

Now that I am new to python, I am not sure what happens to r (a
local variable) after getScreen() returns.  But if it works like
C++, a local variable would be destroyed upon exit of scope,
which is return of function in this case.  Maybe python does not
destroy outright when out of scope, but I imagine that python
would not gurantee the existence of a local variable after the
local var is out of scope, either.

Why I made a fuss on this local var 'r'?  Because r is of class
pixmapRadioButtonGroup, which has the line of the exception:
    def toggled (self, widget):
	if self.togglecb is not None:   <=== exception here.

If r is a local var that could be out of scope, then r.togglecb
might be cleared, depends on what python does to an out-of-scope
var.  The Upgrade button works when you are lucky: python didn't
not overwrite r in your case.  The Upgrade button did not work
for me; I guess python overwrote r in my case.

The above is just a conjecture.  Proof/disproof welcome.

This is pretty thorough analysis. Is some maintainer still watching this?

I think I have enough evidence to confirm the following change would
work.  In examine_gui.py:82, I added this line:
    def getScreen (self, anaconda):
	r = self.createUpgradeOption()  # line 96
        self.r = r                      # *** new line

Then I put this modified examine_gui.py (#1) and original
examine_gui.py (#2) into /tmp/updates/, one after the other, and
ran anaconda (see Appendix A for detail), ie.
    run 1: use #1 (modified, with self.r = r)
    run 2: use #2 (original,   no self.r = r)
    run 3: use #1
    run 4: use #2
    run 5: use #2
    run 6: use #1
    and so on.

And each run with #1 got _no_ exception, each run with #2 got
exception.  At the Install/Upgrade window, I used Alt-U/Alt-I to
choose between Upgrade/Install; sometimes I need to toggle
between Alt-U/Alt-I several times before I got an exception.  I
made about 30 runs in total, and the result was consistent: #1 is
good, #2 is no good.  Once in a while #2 would actually go ok, at
which point I had to power off the PC (thus clears RAM), after
which #2 got exception again.  I see this as the classical
symptom of accessing uninitialized/freed memory space.

To me this is good enough evidence that said modification
mitigates the exception issue, although how this works is not
entirely clear to me, because when I tried a simple python
example in regular linux (not during installation), where I have
a local var that's out of scope (but with a callback assigned to
an in-scope var), followed by allocation of another 100000 obj
(500MB total), the out-of-scope var was not overwritten, unlike
the symptom I observed during installation.

For the record: the python tutorial said that an out-of-scope var is
"forgotten."  What happens to the memory space of a forgotten is not
mentioned.


Even if what I experimented with was all bullshit, what does it
hurt to add a line like this?
        self.r = r

If this info is deemed to be helpful, maybe we can put it into docs/
dir in anaconda package, to make future debug easier.  I didn't find
similar info in anaconda docs/ dir.



Appendix A. Methodology to test anaconda without rebooting every time

This appendix provides a way to test changes to anaconda without
rebooting between every run, and allows on-the-fly changes to anaconda
which could be on CD or DVD.

1. burn Fedora installation CD or DVD as usual.
2. boot from installation CD, in text-mode.  This is very
   important because we need X display :0.0 to be free so we can
   use :0.0 later.
3. At the "Welcome to Fedora!" window, press Ctrl-Alt-F2 to switch 
   to vt2.
4. Copy the anaconda source you wish to change/experiment in
   /usr/lib/anaconda/ to /tmp/updates/.  (See #8 below)
5. Modify files in /tmp/updates/ as desired.
6. run anaconda like this:
        /usr/bin/anaconda -m http://fapa.org --graphical --selinux --noipv6
--lang en.us.UTF-8 --keymap us
   this starts anaconda on :0.0 in vt6 (ctrl-alt-F6).

7. To stop anaconda half-way, switch back to vt2 (ctrl-alt-F2),
   ctrl-c to interrupt anaconda.
   Now you can run anaconda a few times without rebooting.
8. To make the changes persistent across reoot, you may put the 
   files on an USB drive.  USB drive also helps to import files
   from other sources, eg. Internet.

Thanks for the patch.  I've committed this to anaconda and it will be fixed in
the next build.

Thanks for trying out the fix.  We'll see how well it works in
next release.

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