From: Leonardo Boquillon <leonardo.boquillon@tallertechnologies.com>
To: gdb-patches@sourceware.org, tom@tromey.com
Subject: [PING][PATCH] Python: Fix Python error when "Quit"ting a paged info pretty-printers
Date: Tue, 15 Mar 2016 12:53:00 -0000 [thread overview]
Message-ID: <1458046365-21110-1-git-send-email-leonardo.boquillon@tallertechnologies.com> (raw)
Right now the "Quit" command used in the output paging is handled as an exception.
If we issue a "Quit" while outputting the registered pretty-printers list, the
Python handling layer will catch it and think it's a Python error.
The fix is to check if the error coming from Python is a Quit signal. If it is,
do not handle it as an error and resume the execution normally.
Is this ok to commit? I have a company-wide copyright assignment and a coworker
of mine is a write-after-approval maintainer.
gdb/ChangeLog:
2016-03-08 Leonardo Boquillon <leonardo.boquillon@tallertechnologies.com>
* python/py-cmd.c (cmdpy_function): Handle the "Quit" exception.
---
gdb/python/py-cmd.c | 85 +++++++++++++++++++++++++++++------------------------
1 file changed, 47 insertions(+), 38 deletions(-)
diff --git a/gdb/python/py-cmd.c b/gdb/python/py-cmd.c
index af6c5cf..edcaf79 100644
--- a/gdb/python/py-cmd.c
+++ b/gdb/python/py-cmd.c
@@ -165,46 +165,55 @@ cmdpy_function (struct cmd_list_element *command, char *args, int from_tty)
we no longer own ptype, pvalue after the call to PyErr_Restore. */
msg = gdbpy_exception_to_string (ptype, pvalue);
- make_cleanup (xfree, msg);
-
- if (msg == NULL)
- {
- /* An error occurred computing the string representation of the
- error message. This is rare, but we should inform the user. */
- printf_filtered (_("An error occurred in a Python command\n"
- "and then another occurred computing the "
- "error message.\n"));
- gdbpy_print_stack ();
- }
-
- /* Don't print the stack for gdb.GdbError exceptions.
- It is generally used to flag user errors.
-
- We also don't want to print "Error occurred in Python command"
- for user errors. However, a missing message for gdb.GdbError
- exceptions is arguably a bug, so we flag it as such. */
-
- if (! PyErr_GivenExceptionMatches (ptype, gdbpy_gdberror_exc)
- || msg == NULL || *msg == '\0')
- {
- PyErr_Restore (ptype, pvalue, ptraceback);
- gdbpy_print_stack ();
- if (msg != NULL && *msg != '\0')
- error (_("Error occurred in Python command: %s"), msg);
+ /* We need to check this because the "Quit" command used in the output
+ paging is handled as an exception. If we issue a "Quit" while
+ outputting the registered pretty-printers list, the Python handling
+ layer will catch it and think it's a Python error */
+ if (strncmp(msg, "Quit", 5))
+ {
+ if (msg == NULL)
+ {
+ /* An error occurred computing the string representation of the
+ error message. This is rare, but we should inform the user.*/
+ printf_filtered (_("An error occurred in a Python command\n"
+ "and then another occurred computing the "
+ "error message.\n"));
+ gdbpy_print_stack ();
+ }
+
+ /* Don't print the stack for gdb.GdbError exceptions.
+ It is generally used to flag user errors.
+
+ We also don't want to print "Error occurred in Python command"
+ for user errors. However, a missing message for gdb.GdbError
+ exceptions is arguably a bug, so we flag it as such. */
+
+ if (! PyErr_GivenExceptionMatches (ptype, gdbpy_gdberror_exc)
+ || msg == NULL || *msg == '\0')
+ {
+ PyErr_Restore (ptype, pvalue, ptraceback);
+ gdbpy_print_stack ();
+ if (msg != NULL && *msg != '\0')
+ error (_("Error occurred in Python command: %s"), msg);
+ else
+ error (_("Error occurred in Python command."));
+ }
else
- error (_("Error occurred in Python command."));
- }
- else
- {
- Py_XDECREF (ptype);
- Py_XDECREF (pvalue);
- Py_XDECREF (ptraceback);
- error ("%s", msg);
- }
- }
+ {
+ Py_XDECREF (ptype);
+ Py_XDECREF (pvalue);
+ Py_XDECREF (ptraceback);
+ error ("%s", msg);
+ }
+ } // ELSE: This was not an error just quit signal. Do nothing.
- Py_DECREF (result);
- do_cleanups (cleanup);
+ make_cleanup (xfree, msg);
+ }
+ else
+ {
+ Py_DECREF (result);
+ do_cleanups (cleanup);
+ }
}
/* Helper function for the Python command completers (both "pure"
--
1.9.1
next reply other threads:[~2016-03-15 12:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-15 12:53 Leonardo Boquillon [this message]
2016-03-15 15:45 ` Pedro Alves
2016-03-15 17:20 ` Tom Tromey
2016-03-15 17:51 ` Pedro Alves
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=1458046365-21110-1-git-send-email-leonardo.boquillon@tallertechnologies.com \
--to=leonardo.boquillon@tallertechnologies.com \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.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