Bug 374891 - Anaconda exception: pixmapRadioButtonGroup instance has no attribute 'togglecb'
Anaconda exception: pixmapRadioButtonGroup instance has no attribute 'togglecb'
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
9
All Linux
low Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
: 395641 426021 432285 443721 446302 461715 (view as bug list)
Depends On:
Blocks: F10Alpha/F10AlphaBlocker
  Show dependency treegraph
 
Reported: 2007-11-10 12:57 EST by Henrique Martins
Modified: 2008-09-10 09:26 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-19 12:51:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Anaconda generated report (36.00 KB, text/plain)
2007-11-10 12:57 EST, Henrique Martins
no flags Details
Export of exception report (43.90 KB, text/plain)
2007-11-13 11:21 EST, Matthew Dillon
no flags Details
anadonda dump saved when upgrade button was pressed using Alt-U. (53.44 KB, text/plain)
2008-05-16 16:35 EDT, Tim Taiwanese Liim
no flags Details

  None (edit)
Description Henrique Martins 2007-11-10 12:57:31 EST
Description of problem:
  Anaconda crashes when I select Upgrade button

Version-Release number of selected component (if applicable):
  11.3.0.50 (as contained in Fedora 8 DVD)

How reproducible:
  Happened twice

Steps to Reproduce:
1.  Installing F8 from hard drive (SHA1SUM verified)
2.  Click on upgrade once, selected upgrade with keyboard second time
  
Actual results:
  Anaconda crash with message:
  AttributeError: pixmapRadioButtonGroup instance has no attribute 'togglecb'

Attaching anaconda dump/report.
Comment 1 Henrique Martins 2007-11-10 12:57:31 EST
Created attachment 254001 [details]
Anaconda generated report
Comment 2 Jeremy Katz 2007-11-12 14:00:39 EST
Can you reproduce this reliably?
Comment 3 Henrique Martins 2007-11-12 14:16:25 EST
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.
Comment 4 Matthew Dillon 2007-11-13 11:21:34 EST
Created attachment 257011 [details]
Export of exception report
Comment 5 Matthew Dillon 2007-11-13 11:26:17 EST
Comment on attachment 257011 [details]
Export of exception report

Experiencing the same issue, the instant the "Upgrade" option is selected, the
exception occurs.
Comment 6 Matthew Dillon 2007-11-13 11:56:42 EST
I was eventually able to run the upgrade by using the upgrade - text mode 
option from a boot CD.
Comment 7 Chris Lumens 2007-11-27 16:19:33 EST
*** Bug 395641 has been marked as a duplicate of this bug. ***
Comment 8 Adam Pribyl 2007-12-13 03:33:19 EST
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 :).
Comment 9 Chris Lumens 2007-12-17 15:12:29 EST
*** Bug 426021 has been marked as a duplicate of this bug. ***
Comment 10 Charlie Brady 2008-01-15 16:42:51 EST
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, 
Comment 11 Charlie Brady 2008-01-15 16:46:10 EST
I've reproduced, without the 'upgradeany'. It occurred after tab (to select
Install), then down arrow, to move to upgrade. 
Comment 12 Chris Lumens 2008-02-10 23:13:16 EST
*** Bug 432285 has been marked as a duplicate of this bug. ***
Comment 13 Chris Lumens 2008-04-23 03:30:55 EDT
*** Bug 443721 has been marked as a duplicate of this bug. ***
Comment 14 Adam Pribyl 2008-04-24 15:27:33 EDT
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.
Comment 15 Chris Lumens 2008-04-30 14:44:01 EDT
*** Bug 443721 has been marked as a duplicate of this bug. ***
Comment 16 John Poelstra 2008-04-30 14:50:57 EDT
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.
Comment 17 Henrique Martins 2008-04-30 15:19:44 EDT
Fedora 8 was shipped with this bug.  Workaround is install/update in text mode.
 Will trip a few people for sure.
Comment 18 John Poelstra 2008-04-30 17:35:30 EDT
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.
Comment 19 Jeremy Katz 2008-05-01 00:01:55 EDT
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.
Comment 20 John Poelstra 2008-05-01 12:52:22 EDT
tried again today and cannot reproduce... will keep an eye out for it happening
again and try to capture.

moving to F9target blocker
Comment 21 Shawn Starr 2008-05-01 22:19:20 EDT
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
Comment 22 Adam Pribyl 2008-05-03 12:55:30 EDT
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?
Comment 23 Chris Lumens 2008-05-06 18:20:37 EDT
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.
Comment 24 James Laska 2008-05-07 09:24:50 EDT
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.
Comment 25 Will Woods 2008-05-08 18:50:07 EDT
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.
Comment 26 Bug Zapper 2008-05-13 23:52:12 EDT
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
Comment 27 Chris Lumens 2008-05-15 00:12:40 EDT
*** Bug 446302 has been marked as a duplicate of this bug. ***
Comment 28 Tim Taiwanese Liim 2008-05-16 16:35:53 EDT
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'",)
Comment 29 Tim Taiwanese Liim 2008-05-16 17:32:56 EDT
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}
Comment 30 Tim Taiwanese Liim 2008-05-16 18:05:57 EDT
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.
Comment 31 Tim Taiwanese Liim 2008-05-16 18:35:37 EDT
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.
Comment 32 Tim Taiwanese Liim 2008-05-19 00:54:42 EDT
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.
Comment 33 Adam Pribyl 2008-05-20 07:31:28 EDT
This is pretty thorough analysis. Is some maintainer still watching this?
Comment 34 Tim Taiwanese Liim 2008-05-21 22:56:39 EDT
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
Comment 35 Tim Taiwanese Liim 2008-05-21 22:57:13 EDT
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.
Comment 36 Chris Lumens 2008-06-19 12:51:48 EDT
Thanks for the patch.  I've committed this to anaconda and it will be fixed in
the next build.
Comment 37 Tim Taiwanese Liim 2008-06-20 16:38:55 EDT
Thanks for trying out the fix.  We'll see how well it works in
next release.
Comment 38 Chris Lumens 2008-09-10 09:26:16 EDT
*** Bug 461715 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.