From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13817 invoked by alias); 29 Sep 2011 10:51:51 -0000 Received: (qmail 13807 invoked by uid 22791); 29 Sep 2011 10:51:50 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Sep 2011 10:51:36 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1R9EDG-0006Cv-IW from pedro_alves@mentor.com ; Thu, 29 Sep 2011 03:51:34 -0700 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Sep 2011 11:51:32 +0100 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC] Crash sourcing Python script on Windows Date: Thu, 29 Sep 2011 10:54:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.1; x86_64; ; ) Cc: Joel Brobecker , John Spencer References: <1317251996-12146-1-git-send-email-brobecker@adacore.com> <4E83D440.6000702@barfooze.de> <20110929040634.GD19246@adacore.com> In-Reply-To: <20110929040634.GD19246@adacore.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109291151.30633.pedro@codesourcery.com> 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/msg00518.txt.bz2 On Thursday 29 September 2011 05:06:34, Joel Brobecker wrote: > > 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. > > It could be something simpler than that. Python was built on one > system, using an unknown build environment. when then use that > library to link it against some code on a version of Windows that > is most likely different, with a compiler that is also most likely > different. If each compiler used a libc where the definition of > that type is different, then we have an incompatibility. It is much more likely that your python is linked with a C runtime, while gdb is linked with another. Try "info sharedlibrary", and you'll probably see both msvcrXX.dll and both msvcrt.dll loaded. There's not a single/main C runtime on a Windows system. The C runtime on Windows is not a central part of the whole system runtime like tradicionally on Unix. The NT api (and Win32 on top) fills that central role. There's msvcrt.dll, originally part of Visual C++, but which is bundled in Windows nowadays (*), and then there's the msvcrtd.dll, the debug variant, and then Visual Studio will default to link with a different C runtime, and a different one for each version, going by msvcrXXX.dll names (with XXX being 70, 80, 90, 100, etc.) It is common to end up with more than one C runtime loaded on Windows. Windows dlls are self contained, and all its symbols must be defined at link-time. There's no symbol interposition concept in PE. If you have your application linked with, say, msvcrt.dll, which is what mingw links with by default, and you load a Dll that was linked with, say, msvcr70.dll, you'll end up with both C runtimes loaded in the process. Each of the runtimes will have its own separate internal state. That's the crux. Given that, you need to be careful to not pass/use C runtime objects across dlls. E.g., if you malloc in dll/executable A, you can pass that around to other dlls, but you should `free' that memory back on dll/executable A, so that the proper runtime is called. If you had free'd memory in dll B instead (which was linked against a different runtime, hence you call a different `free' function), B's C runtime would have no clue what that pointer was -- it's just gargabe from its perpective, and you'd likely crash. Same with FILE*, and file descriptions. Each runtime maintains its own internal state for those. In a nutshell, your patch is correct. If such a fix is not always possible, then we'll have to make sure you link the same runtime in all the offending dlls (those that pass around C runtime objects). -- Pedro Alves