kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Goldish <mgoldish@redhat.com>
To: Ryan Harper <ryanh@us.ibm.com>
Cc: kvm@vger.kernel.org
Subject: Re: kvm-autotest: weird memory error during stepmaker test
Date: Thu, 2 Apr 2009 03:07:31 -0400 (EDT)	[thread overview]
Message-ID: <1320454602.3722661238656051258.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> (raw)
In-Reply-To: <1649348235.3722371238655648751.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>

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" <ryanh@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
ryanh@us.ibm.com
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

       reply	other threads:[~2009-04-02  7:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1649348235.3722371238655648751.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2009-04-02  7:07 ` Michael Goldish [this message]
     [not found] <479395147.3950621238794089916.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2009-04-03 21:33 ` kvm-autotest: weird memory error during stepmaker test Michael Goldish
2009-04-01 15:55 Ryan Harper
2009-04-03 20:37 ` Eduardo Habkost

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1320454602.3722661238656051258.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com \
    --to=mgoldish@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=ryanh@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).