I've never seen this exception before (and I've used stepmaker quite a bit).
The last line in the traceback is a call to gtk.gdk.pixbuf_new_from_data, so it
might be PyGTK's fault, but I can't be sure.
This is what the docs have to say:
exception MemoryError
Raised when an operation runs out of memory but the situation may still be
rescued (by deleting some objects). The associated value is a string indicating
what kind of (internal) operation ran out of memory. Note that because of the
underlying memory management architecture (C’s malloc function), the
interpreter may not always be able to completely recover from this situation;
it nevertheless raises an exception so that a stack traceback can be printed,
in case a run-away program was the cause.
It seems that in this case the exception had no associated value, so it'll be
hard to tell what caused it.
In any case, if the guest is still alive and stepmaker dies for some reason,
there are 2 things you can do:
1. Re-run stepmaker with a living VM:
Kill autotest (not with ctrl+c), and if the kvm-autotest postprocessor doesn't
kill your VM (either because it wasn't told to with kill_vm=yes, or because
autotest was killed before the postprocessor could run) -- the VM will stay
alive and untouched. Then you can modify the config file so the preprocessor
doesn't touch the VM or the image (e.g. force_create_image=no, restart_vm=no,
or just make sure they're not set to 'yes' anywhere), change the name of the
steps file to be written (stepmaker won't run if the file already exists), and
re-run stepmaker. It will run with the same living VM and continue exactly
where you left off. Then you just need to concatenate the two stepfiles with
stepeditor, and maybe make a few small fixes.
Note:
- If you press ctrl+c autotest will kill all subprocesses started in the
current run, including your VM. You should kill autotest somehow without
ctrl+c. "killall autotest" and "killall -9 autotest" worked for me.
- If you run stepmaker by changing the 'type' of an install test to
'stepmaker', remember that this test inherits the parameters of the 'install'
variant defined at the top of the file, which typically include
force_create_image=yes, which will overwrite the disk image with a blank one,
which is a bad thing if you want to re-run stepmaker with the same VM.
2. Restart the installation from an advanced point:
If the VM is already dead, and you can somehow resume the installation so that
you don't have to start from scratch (maybe start from the first boot?), you
can do that with stepmaker and then concatenate the two stepfiles and use
stepeditor to remove duplicate steps.
Please let me know if you ever encounter that weird memory exception again.
Thanks,
Michael
----- Original Message -----
From: "Ryan Harper" <ry...@us.ibm.com>
To: kvm@vger.kernel.org
Sent: Wednesday, April 1, 2009 6:55:58 PM (GMT+0200) Auto-Detected
Subject: kvm-autotest: weird memory error during stepmaker test
Wondering if anyone else using kvm-autotest stepmaker has ever seen this
error:
Traceback (most recent call last):
File
"/home/rharper/work/git/build/kvm-autotest/client/tests/kvm_runtest_2/stepmaker.py",
line 146, in update
self.set_image_from_file(self.screendump_filename)
File
"/home/rharper/work/git/build/kvm-autotest/client/tests/kvm_runtest_2/stepeditor.py",
line 499, in set_image_from_file
self.set_image(w, h, data)
File
"/home/rharper/work/git/build/kvm-autotest/client/tests/kvm_runtest_2/stepeditor.py",
line 485, in set_image
w, h, w*3))
MemoryError
The guest is still running, but stepmaker isn't recording any more so it's
boned at that point. And of course, it's near the end of a guest install so
one has lost a decent amount of time...
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.com
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
