[PATCH] fix error handler index in xm

[PATCH] fix error handler index in xm

[Dan Smith]

[-- Attachment #1: Type: text/plain, Size: 182 bytes --]

This patch fixes a typo in xm's main.py.  This fixes the exception
thrown when doing, for example, "xm domid" on a non-existent domain.

Signed-off-by: Dan Smith <danms@us.ibm.com>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xm.patch --]
[-- Type: text/x-patch, Size: 492 bytes --]

diff -r 522bc50588ed tools/python/xen/xm/main.py
--- a/tools/python/xen/xm/main.py	Tue Aug 23 18:27:22 2005
+++ b/tools/python/xen/xm/main.py	Tue Aug 23 13:02:58 2005
@@ -666,7 +666,7 @@
             sys.exit(1)
         except XendError, ex:
             if len(args) > 0:
-                handle_xend_error(argv[1], args[1], ex)
+                handle_xend_error(argv[1], args[0], ex)
             else:
                 print "Unexpected error:", sys.exc_info()[0]
                 print

[-- Attachment #3: Type: text/plain, Size: 89 bytes --]


-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@us.ibm.com


[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] fix error handler index in xm

[Christian Limpach]

Thanks!

On 8/23/05, Dan Smith <danms@us.ibm.com> wrote:
> This patch fixes a typo in xm's main.py.  This fixes the exception
> thrown when doing, for example, "xm domid" on a non-existent domain.
> 
> Signed-off-by: Dan Smith <danms@us.ibm.com>
> 
> 
> 
> 
> --
> Dan Smith
> IBM Linux Technology Center
> Open Hypervisor Team
> email: danms@us.ibm.com
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 
>

Re: [PATCH] fix error handler index in xm

[Christian Limpach]

On 8/23/05, Dan Smith <danms@us.ibm.com> wrote:
> This patch fixes a typo in xm's main.py.  This fixes the exception
> thrown when doing, for example, "xm domid" on a non-existent domain.

I've reverted this check-in because with the change applied, the error
messages are incorrect:
moonbase-0:~# xm destroy vm7
Error: Domain 'bogus' not found when running 'xm destroy'

Please provide before/after examples when sending patches to the tools.

     christian

Re: [PATCH] fix error handler index in xm

[Dan Smith]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]


CL> I've reverted this check-in because with the change applied, the
CL> error messages are incorrect: 

Ok, so the problem is rooted in the way the args list is manipulated
in the subcommand handlers.  As it stands now (without the patch),
some commands give a good error message, while others dump a stack
trace if the domain doesn't exist:

  # xm destroy foo
  Error: Domain 'foo' not found when running 'xm destroy'
  # xm domid foo
  Traceback (most recent call last):
    File "/usr/sbin/xm", line 10, in ?
      main.main(sys.argv)
    File "/usr/lib/python/xen/xm/main.py", line 671, in main
      handle_xend_error(argv[1], args[1], ex)
  IndexError: list index out of range

This is because destroy adds "bogus" into the args list at index 0,
but domid does not.  I've attached a new patch that checks for this
condition, and removes the "bogus" entry from the list if the
subcommand added it.  This makes the call to handle_xend_error() work
in both situations:

  # xm destroy foo
  Error: Domain 'foo' not found when running 'xm destroy'
  # xm domid foo
  Error: Domain 'foo' not found when running 'xm domid'

Is that an acceptable solution for now?  Perhaps a cleanup of the
inconsistent subcommand handler behavior is in order.  I can do that
when I start work on the remaining interface changes.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xm_new.patch --]
[-- Type: text/x-patch, Size: 645 bytes --]

diff -r b74c15e4dd4f tools/python/xen/xm/main.py
--- a/tools/python/xen/xm/main.py	Wed Aug 24 16:15:42 2005
+++ b/tools/python/xen/xm/main.py	Wed Aug 24 09:36:32 2005
@@ -665,8 +665,10 @@
             err("Most commands need root access.  Please try again as root")
             sys.exit(1)
         except XendError, ex:
+            if args[0] == "bogus":
+                args.remove("bogus")
             if len(args) > 0:
-                handle_xend_error(argv[1], args[1], ex)
+                handle_xend_error(argv[1], args[0], ex)
             else:
                 print "Unexpected error:", sys.exc_info()[0]
                 print

[-- Attachment #3: Type: text/plain, Size: 88 bytes --]


-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@us.ibm.com

[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] fix error handler index in xm

[Christian Limpach]

On Wed, Aug 24, 2005 at 10:07:22AM -0700, Dan Smith wrote:
> CL> I've reverted this check-in because with the change applied, the
> CL> error messages are incorrect: 
> 
> Ok, so the problem is rooted in the way the args list is manipulated
> in the subcommand handlers.  As it stands now (without the patch),
> some commands give a good error message, while others dump a stack
> trace if the domain doesn't exist:

Ah, ok.

> This is because destroy adds "bogus" into the args list at index 0,
> but domid does not.  I've attached a new patch that checks for this
> condition, and removes the "bogus" entry from the list if the
> subcommand added it.  This makes the call to handle_xend_error() work
> in both situations:
> 
>   # xm destroy foo
>   Error: Domain 'foo' not found when running 'xm destroy'
>   # xm domid foo
>   Error: Domain 'foo' not found when running 'xm domid'
> 
> Is that an acceptable solution for now?  Perhaps a cleanup of the
> inconsistent subcommand handler behavior is in order.  I can do that
> when I start work on the remaining interface changes.

Yes, I've checked this in for now, but making the subcommand handler
behavious consistent would be good.

    christian