From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6493 invoked by alias); 1 Mar 2012 22:44:57 -0000 Received: (qmail 6483 invoked by uid 22791); 1 Mar 2012 22:44:56 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW,TW_BJ,TW_YG X-Spam-Check-By: sourceware.org Received: from out5-smtp.messagingengine.com (HELO out5-smtp.messagingengine.com) (66.111.4.29) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Mar 2012 22:44:42 +0000 Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 4FC4920E62 for ; Thu, 1 Mar 2012 17:44:42 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 01 Mar 2012 17:44:42 -0500 Received: from [158.147.136.150] (158-147-136-150.harris.com [158.147.136.150]) by mail.messagingengine.com (Postfix) with ESMTPSA id 08DD64824B3; Thu, 1 Mar 2012 17:44:41 -0500 (EST) Message-ID: <4F4FFBD8.1080803@cwilson.fastmail.fm> Date: Thu, 01 Mar 2012 22:44:00 -0000 From: Charles Wilson Reply-To: Charles Wilson User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: cygheap base mismatch detected References: <4F4E7CC8.9090804@cwilson.fastmail.fm> <20120301105139.GF2257@calimero.vinschen.de> <20120301121442.GG2257@calimero.vinschen.de> In-Reply-To: <20120301121442.GG2257@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-03/txt/msg00054.txt.bz2 On 3/1/2012 7:14 AM, Corinna Vinschen wrote: > Hmm. cygcheck loads the Cygwin DLL dynamically. It does not depend on > any other Cygwin distro DLL. But it's started from a Cygwin parent. So > the loaded CYgwin DLL checks the layout just like it had been linked > against. And apparently it gets rebased at load time. Which means to > me, there's another DLL already loaded into the process at an address > which overlaps with the address space the Cygwin DLL should have been > loaded to. > > So I guess you just have to find out what is the cause for rebasing > the Cygwin DLL. Try VMMap from sysinternals with a cygcheck -svr piped > into less, so that you can easily observe the process in vmmap. It appears to be C:\WINDOWS\SysWOW64\PGHook.dll which is part of Avecto Privilege Guard (which could certainly be classed as a BLODA IMO; thank you paranoid corporate IT policies...). For cygcheck, PGHook.dll gets loaded at its desired image base: $ objdump -p /c/Windows/syswow64/pghook.dll |grep ImageBase ImageBase 61100000 So, it appears that for normal cygwin processes, PGHook gets rebased elsewhere, and cygwin "wins." For instance, /bin/top.exe -> PGHook gets loaded at 01FD000, b/c cygwin1.dll is already at 0x61000000. OTOH, there's nothing in the cygcheck.exe process that prevents PGHook from getting its desired base addr -- which then conflicts with cygwin's desired base addr when it is (later) dynloaded. Is there some workaround that could be used? It's not as if cygcheck is really trying to initialize and *use* cygwin1.dll facilities, is it? So, perhaps cygwin1.dll/dcrt0 could ignore the fact that it has been rebased, when dynamically loaded? (or perhaps, only when dynloaded by some app named 'cygcheck.exe'). -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple