Problem embedding Python.

[Brandon Keown]

I am going to try to embed python in an application, but in simple
testing, I could not get it to work. The following code seems like it
should work, but it crashes, and I have tried several things. What
could I be doing wrong?

#include <Python.h>

int main(int argc, char* argv[])
{
FILE* fp = fopen("test.py","r");
Py_Initialize();
PyRun_SimpleFile(fp,"test.py");
Py_Finalize();
return 0;
}

 

[Gabriel Genellina]

En Tue, 27 Oct 2009 03:25:54 -0300, Brandon Keown

I am going to try to embed python in an application, but in simple
testing, I could not get it to work. The following code seems like it
should work, but it crashes, and I have tried several things. What
could I be doing wrong?

#include <Python.h>

int main(int argc, char* argv[])
{
FILE* fp = fopen("test.py","r");
Py_Initialize();
PyRun_SimpleFile(fp,"test.py");
Py_Finalize();
return 0;
}

Crashes, how? Try running inside a debugger to see where it crashes, or at
least put a few printf.
You didn't test for the fopen result; are you sure "test.py" exists in the
current directory at the time you run it?

 

[Brandon Keown]

Crashes, how? Try running inside a debugger to see where it crashes, or at  
least put a few printf.
You didn't test for the fopen result; are you sure "test.py" exists in the  
current directory at the time you run it?

Ok, so I assumed that the file, if supplied without a path, would use
current working directory, which was evidently a false assumption. I
put in an if statement to check to see if the pointer was null which
it was. So I fully qualified the path in the test file. Now it
throws an unhandled exception when it goes to execute the line with
PyRun_SimpleFile. The following code yields the errors after it.

#include <Python.h>

int main(int argc, char* argv[])
{
FILE* fp = fopen("c:\\Patches\\Test\\Debug\\test.py","w");
if(fp == NULL)
printf("error");
Py_Initialize();
PyRun_SimpleFile(fp,"test.py");
Py_Finalize();
return 0;
}

"First-chance exception at 0x77d2dbba in Test.exe: 0xC0000005: Access
violation writing location 0x00000014.
Unhandled exception at 0x77d2dbba in Test.exe: 0xC0000005: Access
violation writing location 0x00000014.
First-chance exception at 0x77d2dbba in Test.exe: 0xC0000005: Access
violation writing location 0x00000014.
Unhandled exception at 0x77d2dbba in Test.exe: 0xC0000005: Access
violation writing location 0x00000014."

In the debug output.

This is the call stack (the first line is where execution halted).

Test.exe!main(int argc=1, char** argv=0x006d1b88) Line 9 + 0x15 bytes
Test.exe!__tmainCRTStartup() Line 586 + 0x19 bytes
Test.exe!mainCRTStartup() Line 403

(There is more after this, but it goes back to system calls and
execution is halted here so I thought this was relevant).

 

[Brandon Keown]

I found the problem. Evidently as posted on a few other areas of the
internet, this is a common problem when trying to use compilers that
may have different type definitions for (FILE*). Here is workable
solution:

#include <Python.h>

int main(int argc, char* argv[])
{
PyObject* PyFileObject;
char* filename;
Py_Initialize();
filename = "c:\\Patches\\Test\\Debug\\test.py";
PyFileObject = PyFile_FromString(filename, "r");
PyRun_SimpleFile(PyFile_AsFile(PyFileObject), filename);
Py_Finalize();
return 0;
}

 

[Gabriel Genellina]

En Tue, 27 Oct 2009 06:36:18 -0300, Brandon Keown

Ok, so I assumed that the file, if supplied without a path, would use
current working directory, which was evidently a false assumption.

Now that you've solved your problem, revise your conclusion. A file
without a path *is* searched in the current working directory - but that
directory may not be the one you think it is.

 

[Brandon Keown]

En Tue, 27 Oct 2009 06:36:18 -0300, Brandon Keown



Now that you've solved your problem, revise your conclusion. A file
without a path *is* searched in the current working directory - but that
directory may not be the one you think it is.

I'm not sure what you mean. I executed the program from the directory
the file was in, they were in the same directory. And when a program
executes from a path in CMD in windows, that is supposed to be the
CWD. I'm not sure what it would be set to if not that...

 

[Dave Angel]

I'm not sure what you mean. I executed the program from the directory
the file was in, they were in the same directory. And when a program
executes from a path in CMD in windows, that is supposed to be the
CWD. I'm not sure what it would be set to if not that...

Gabriel is right. But if you care to get our diagnosis, you need to
state your working conditions more clearly. Or perhaps do a bit of
debugging on it. For a start, you might do a print os.curdir right
before the open() function to see what the current directory is.

Or you could remove the several ambiguities in your paragraph above that
starts "I'm not sure..." Maybe show a transcript of your CMD session.
And if the python.* that's on your PATH is a batch file, show us the
contents of that as well.

And if you're running from CMD, or from an interpreter, or from IDLE, or
from an IDE, or from Explorer, each one may have its own idea of what to
give you for current directory.

If you're running the script from a CMD prompt, by just entering the
script name and letting Windows find the executable (which is not the
script), then you're correct, CWD should be the same as it was in the
CMD shell.

DaveA

 

[Brandon Keown]

O...K...

 

[Dave Angel]

Gabriel is right. But if you care to get our diagnosis, you need to
state your working conditions more clearly. Or perhaps do a bit of
debugging on it. For a start, you might do a print os.curdir
right before the open() function to see what the current directory is.

Or you could remove the several ambiguities in your paragraph above
that starts "I'm not sure..." Maybe show a transcript of your CMD
session. And if the python.* that's on your PATH is a batch file,
show us the contents of that as well.

And if you're running from CMD, or from an interpreter, or from IDLE,
or from an IDE, or from Explorer, each one may have its own idea of
what to give you for current directory.

If you're running the script from a CMD prompt, by just entering the
script name and letting Windows find the executable (which is not the
script), then you're correct, CWD should be the same as it was in the
CMD shell.

DaveA

OK, I blew it. Instead of re-reading the thread, I relied on memory.
So please cancel my last paragraph, and let me try again.

The big differences between your working code and the non-working code
are three:
The non-working code uses relative file name, while the working code
uses absolute path.
The non-working code uses C's open() call, while the working code
changed that to PyFile_FromString(filename, "r")
The non-working code uses "w" mode on the open, trashing the file,
while the working code uses "r"

I'd claim that #3 is your real problem. I doubt that a file open in "w"
mode is acceptable to the interpreter, since the first thing that does
is truncate the file.

Anyway, Gabriel's point (which I poorly elaborated on) about the current
directory is still valid. But you should use C calls to see what it is,
rather than Python calls. And I'd still like to know how you're
launching this executable, this compiled C program. If you're running
it from a CMD window, a DOS box, then the current directory is obvious
from the prompt.

DaveA