Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Paul Koning <paulkoning@comcast.net>
To: gdb-patches@sourceware.org, Tom Tromey <tromey@redhat.com>,
	Phil Muldoon <pmuldoon@redhat.com>
Subject: Re: [python] [patch] PR python/13331
Date: Mon, 24 Oct 2011 15:39:00 -0000	[thread overview]
Message-ID: <966B9848-BA1E-4777-BCE3-FD57AEA6E989@comcast.net> (raw)
In-Reply-To: <09787EF419216C41A903FD14EE5506DD030CE5E15C@AUSX7MCPC103.AMER.DELL.COM>


> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Tom Tromey
> Subject: Re: [python] [patch] PR python/13331
> 
>>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:
> 
> Phil> 2011-10-24  Phil Muldoon  <pmuldoon@redhat.com>
> Phil>         PR python/13331
> Phil> 	* python/py-function.c (fnpy_call): Check 'args' is not NULL.
> Phil> 	(convert_values_to_python): Return on Python tuple allocation
> Phil> 	failure.
> 
> Phil> +  if (! result)
> Phil> +    return NULL;
> 
> I think the function should have a single return convention.
> One easy way to do that would be to remove the 'error' call and have it return NULL when value_to_value_object fails.

I think the patch is not quite right because it goes against the Python rule for exception handling.  A NULL function result is the normal way to indicate an error, but associated with returning NULL is that in the spot where the error is first detected you set the exception status.  And in addition, anywhere else NULL is propagated (with any necessary cleanup) but the exception status is *not* overwritten.

> ...
> Index: python/py-function.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/python/py-function.c,v
> retrieving revision 1.10
> diff -u -r1.10 py-function.c
> --- python/py-function.c	5 Aug 2011 14:24:10 -0000	1.10
> +++ python/py-function.c	24 Oct 2011 13:15:38 -0000
> @@ -38,6 +38,9 @@
> {
>   int i;
>   PyObject *result = PyTuple_New (argc);
> +  
> +  if (! result)
> +    return NULL;
> 
>   for (i = 0; i < argc; ++i)
>     {

In this loop there is an example of what I mentioned: if value_to_value_object returns NULL, exception status has been set, and that should not be overwritten here.  On the other hand, there is missing cleanup: any objects added to the tuple before the failing call need to have a DECREF done on them.


> @@ -59,24 +62,35 @@
> 	   void *cookie, int argc, struct value **argv)  {
>   struct value *value = NULL;
> -  PyObject *result, *callable, *args;
> +  /* 'result' must be set to NULL, this initially indicates whether
> +     the function was called, or not.  */  PyObject *result = NULL;  
> + PyObject *callable, *args;
>   struct cleanup *cleanup;
> 
>   cleanup = ensure_python_env (gdbarch, language);
> 
>   args = convert_values_to_python (argc, argv);
> +  /* convert_values_to_python can return NULL on error.  If we
> +     encounter this, do not call the function, but allow the Python ->
> +     error code conversion below to deal with the Python exception.
> +     Note, that this is different if the function simply does not
> +     have arguments.  */
> 
> -  callable = PyObject_GetAttrString ((PyObject *) cookie, "invoke");
> -  if (! callable)
> +  if (args)
>     {
> +      callable = PyObject_GetAttrString ((PyObject *) cookie, "invoke");
> +      if (! callable)
> +	{
> +	  Py_DECREF (args);
> +	  error (_("No method named 'invoke' in object."));

That should just be a cleanup and return NULL -- the PyObject_GetAttrString has set the exception.

	paul


  parent reply	other threads:[~2011-10-24 15:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-24 13:30 Phil Muldoon
2011-10-24 13:57 ` Tom Tromey
     [not found]   ` <09787EF419216C41A903FD14EE5506DD030CE5E15C@AUSX7MCPC103.AMER.DELL.COM>
2011-10-24 15:39     ` Paul Koning [this message]
2011-10-24 15:47       ` Tom Tromey
2011-10-24 15:52         ` Paul Koning
2011-10-24 16:00       ` Phil Muldoon
2011-10-24 16:06         ` Paul Koning
2011-10-27 10:59   ` Phil Muldoon

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=966B9848-BA1E-4777-BCE3-FD57AEA6E989@comcast.net \
    --to=paulkoning@comcast.net \
    --cc=gdb-patches@sourceware.org \
    --cc=pmuldoon@redhat.com \
    --cc=tromey@redhat.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