From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 397 invoked by alias); 29 Sep 2011 09:48:47 -0000 Received: (qmail 387 invoked by uid 22791); 29 Sep 2011 09:48:47 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Sep 2011 09:48:33 +0000 Received: by vws16 with SMTP id 16so349670vws.0 for ; Thu, 29 Sep 2011 02:48:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.175.133 with SMTP id ca5mr9220870vdc.245.1317289712662; Thu, 29 Sep 2011 02:48:32 -0700 (PDT) Received: by 10.220.180.5 with HTTP; Thu, 29 Sep 2011 02:48:32 -0700 (PDT) In-Reply-To: <83r52zelj5.fsf@gnu.org> References: <1317251996-12146-1-git-send-email-brobecker@adacore.com> <09787EF419216C41A903FD14EE5506DD03098D555B@AUSX7MCPC103.AMER.DELL.COM> <4E83D440.6000702@barfooze.de> <20110929040634.GD19246@adacore.com> <83ty7verow.fsf@gnu.org> <83r52zelj5.fsf@gnu.org> Date: Thu, 29 Sep 2011 09:51:00 -0000 Message-ID: Subject: Re: [RFC] Crash sourcing Python script on Windows From: Kai Tietz To: Eli Zaretskii Cc: brobecker@adacore.com, maillist-gdbpatches@barfooze.de, gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00513.txt.bz2 2011/9/29 Eli Zaretskii : >> Date: Thu, 29 Sep 2011 10:38:51 +0200 >> From: Kai Tietz >> Cc: Joel Brobecker , maillist-gdbpatches@barfooze= .de, >> =A0 =A0 =A0 gdb-patches@sourceware.org >> >> The issue here is not the definition of the FILE type itself in this >> case. =A0The problem is that python (if built with VC) uses different >> runtime-version (msvcr100.dll or lower), but mingw uses by well know >> reasons the msvcrt.dll. =A0So by loading this python-DLL into a >> mingw-built executable, we have two different runtimes at the same >> time. > > Thanks, this makes sense. > > What are the reasons that we build GDB against msvcrt.dll? The issue is a legal thing. The newer runtimes mvcrXX.dlls aren't part of the OS itself. The msvcrt.dll is present on all WIndows OSes (well always in a different version). So we can assume that everybody has a working msvcrt.dll present on his OS. Due the fact that msvcrXX.dll aren't part of runtime, you would need to distribute those DLLs to end-user, which would be (INAL) a violation of EULA as far as I understood it, if you haven't a VC license for it. >> By the way, the same issue can lead also for different C-runtime >> functions pretty funny results. > > Exactly. =A0If we have such an incompatibility once python's DLL is > loaded, it can lead to similar crashes elsewhere. =A0So, unless we can > find a way of linking against msvcrNNN.dll or build our own Python > with MinGW, it sounds like using Python on Windows is unsafe? Well, not necessarily. You need just to take care that file-I/O and memory-functions are used only in context of one of those libraries and no exchange of those pointers/file-handles (on C-level, not OS-level) happens. For example Java-VM-Runtime works that way pretty nice with msvcrt, as long as you take care not to do here those failures. Regards, Kai