This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Crash sourcing Python script on Windows


On 09/29/2011 03:01 AM, Paul_Koning@Dell.com wrote:
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.
That sounds like a good solution. I'm puzzled though -- how did FILE end up being different? One would expect the right header files to be used, producing correct/consistent results. If that didn't happen in this case, could it happen for other aspects of the GDB to Python API?

paul

FILE is supposed to be an opaque type and as such noone except of the libc which defines it is supposed to "poke" at its internals.
however it is common practice in GNU software to assume everybody uses GLIBC and poke around in internal stuff thats not supposed to be accessibly at all in userland. another example of such illegal behaviour is libevent, which does illegal things with fd_set internals to allow more than FD_SETSIZE file descriptors to be used with select().



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]