From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30794 invoked by alias); 29 Sep 2011 02:16:06 -0000 Received: (qmail 30765 invoked by uid 22791); 29 Sep 2011 02:16:05 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from barfooze.de (HELO barfooze.de) (78.46.117.212) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Sep 2011 02:15:49 +0000 Received: from xdsl-188-155-204-78.adslplus.ch ([188.155.204.78] helo=[172.16.0.230]) by barfooze.de with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1R96A6-0001WM-7q for gdb-patches@sourceware.org; Thu, 29 Sep 2011 04:15:46 +0200 Message-ID: <4E83D440.6000702@barfooze.de> Date: Thu, 29 Sep 2011 02:19:00 -0000 From: John Spencer User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Mail/1.0 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [RFC] Crash sourcing Python script on Windows References: <1317251996-12146-1-git-send-email-brobecker@adacore.com> <09787EF419216C41A903FD14EE5506DD03098D555B@AUSX7MCPC103.AMER.DELL.COM> In-Reply-To: <09787EF419216C41A903FD14EE5506DD03098D555B@AUSX7MCPC103.AMER.DELL.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00494.txt.bz2 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().