From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Cc: Joel Brobecker <brobecker@adacore.com>
Subject: [RFC] Crash sourcing Python script on Windows
Date: Wed, 28 Sep 2011 23:24:00 -0000 [thread overview]
Message-ID: <1317251996-12146-1-git-send-email-brobecker@adacore.com> (raw)
Hello,
At long last, I forced myself to look into this. I had noticed
that "source script.py" did not work on Windows, and resulted
in the debugger crashing. It turns out that the problem came
from the fact that I was using a binaries from python.org where
the definition of type FILE difers from the definition our
compiler uses. The crash occurs when trying to call PyRun_SimpleFile
with a FILE created by GDB.
The approach we took is to create a new FILE descriptor using
Python routines, thus making sure that the FILE is compatible
with PyRun_SimpleFile. There were two such calls, so we wrote
a wrapper to that function that only takes a filename, and creates
the FILE on the fly. This avoids code duplication.
We typically build Python ourselves on all platforms, except
Windows, where the build setup is a lot different. That's why
we have only ever seen this problem there. Still, this is
arguably a problem that could occur on other systems, even if
I somehow doubt it (this is a guess!). As a result, I decided
to apply the workaround unconditionally on all platforms.
I don't see this as a big performance impact in practice.
The internet if full of references to people hitting the same
problem. So I think we should make an attempt at preventing
this from happening. As said above, building Python on Windows
is hard, so we shouldn't expect typical developers to do themselves.
The question, hence the RFC, is: can anyone see a better way?
I thought about reading the entire script from stream to a string,
and then feeding that to PyRun_SimpleString. That would work too,
I think. But reading a file into a string means that we'd have
to have the entire file in memory, whereas the python interpreter
might have a smarter strategy.
Anyways, open to other options...
gdb/ChangeLog:
* python/python.c (python_run_simple_file): New function.
(source_python_script, source_python_script_for_objfile):
Replace call to PyRun_SimpleFile by call to
python_run_simple_file.
Tested on x86_64-linux, and on x86-windows (with AdaCore's testsuite).
Thanks!
--
Joel
---
gdb/python/python.c | 36 ++++++++++++++++++++++++++++++++++--
1 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/gdb/python/python.c b/gdb/python/python.c
index 4ef5715..5fef62f 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -134,6 +134,38 @@ ensure_python_env (struct gdbarch *gdbarch,
return make_cleanup (restore_python_env, env);
}
+/* A wrapper around PyRun_SimpleFile. FILENAME is the name of
+ the Python script to run.
+
+ One of the parameters of PyRun_SimpleFile is a FILE *.
+ The problem is that type FILE is extremely system and compiler
+ dependent. So, unless the Python library has been compiled using
+ the same build environment as GDB, we run the risk of getting
+ a crash due to inconsistencies between the definition used by GDB,
+ and the definition used by Python. A mismatch can very likely
+ lead to a crash. This is particularly visible on Windows, where
+ few users would build Python themselves (this is no trivial task
+ on this platform), and thus use binaries built by someone else
+ instead.
+
+ To work around this potential issue, we create the FILE object
+ using Python routines, thus making sure that it is compatible
+ with the Python library. */
+
+static void
+python_run_simple_file (const char *filename)
+{
+ char *filename_copy;
+ PyObject* python_file;
+ struct cleanup *cleanup;
+
+ filename_copy = xstrdup (filename);
+ cleanup = make_cleanup (xfree, filename_copy);
+ python_file = PyFile_FromString(filename_copy, "r");
+ make_cleanup_py_decref (python_file);
+ PyRun_SimpleFile (PyFile_AsFile (python_file), filename);
+ do_cleanups (cleanup);
+}
/* Given a command_line, return a command string suitable for passing
to Python. Lines in the string are separated by newlines. The
@@ -573,7 +605,7 @@ source_python_script (FILE *stream, const char *file)
/* Note: If an exception occurs python will print the traceback and
clear the error indicator. */
- PyRun_SimpleFile (stream, file);
+ python_run_simple_file (file);
do_cleanups (cleanup);
}
@@ -917,7 +949,7 @@ source_python_script_for_objfile (struct objfile *objfile,
cleanups = ensure_python_env (get_objfile_arch (objfile), current_language);
gdbpy_current_objfile = objfile;
- PyRun_SimpleFile (stream, file);
+ python_run_simple_file (file);
do_cleanups (cleanups);
gdbpy_current_objfile = NULL;
--
1.7.1
next reply other threads:[~2011-09-28 23:20 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-28 23:24 Joel Brobecker [this message]
2011-09-29 2:00 ` Paul_Koning
2011-09-29 2:19 ` John Spencer
2011-09-29 4:47 ` Joel Brobecker
2011-09-29 7:30 ` Eli Zaretskii
2011-09-29 8:54 ` Kai Tietz
2011-09-29 9:48 ` Eli Zaretskii
2011-09-29 9:51 ` Kai Tietz
2011-09-29 10:54 ` Pedro Alves
2011-09-29 12:33 ` Eli Zaretskii
2011-09-29 12:48 ` Kai Tietz
2011-09-29 13:19 ` Pedro Alves
2011-09-29 7:26 ` Eli Zaretskii
2011-10-03 20:05 ` Tom Tromey
2011-09-29 7:20 ` Eli Zaretskii
2011-10-03 20:02 ` Tom Tromey
2011-10-03 20:53 ` Joel Brobecker
2011-10-04 17:08 ` Tom Tromey
2012-01-23 18:14 ` [patch] Do not open Python scripts twice #2 [Re: [RFC] Crash sourcing Python script on Windows] Jan Kratochvil
2012-01-23 18:41 ` Pedro Alves
2012-01-23 21:55 ` Jan Kratochvil
2012-01-23 22:08 ` Doug Evans
2012-01-23 22:47 ` Jan Kratochvil
2012-01-23 23:47 ` Doug Evans
2012-01-24 14:45 ` Jan Kratochvil
2012-01-24 18:56 ` Doug Evans
2012-01-24 19:41 ` Jan Kratochvil
2012-01-24 22:20 ` Doug Evans
2012-01-24 23:49 ` Jan Kratochvil
2012-01-25 22:30 ` Jan Kratochvil
2012-01-26 7:18 ` Joel Brobecker
2012-01-26 22:03 ` [commit] " Jan Kratochvil
2012-01-24 15:15 ` Pedro Alves
2012-01-23 19:57 ` 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=1317251996-12146-1-git-send-email-brobecker@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/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