From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9079 invoked by alias); 20 Apr 2016 10:28:26 -0000 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 Received: (qmail 9062 invoked by uid 89); 20 Apr 2016 10:28:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,FSL_HELO_BARE_IP_2,RCVD_IN_DNSWL_LOW,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 spammy=installations, installs, dab, rwp X-HELO: plane.gmane.org Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 20 Apr 2016 10:28:15 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aspMV-0004gm-Q6 for cygwin@cygwin.com; Wed, 20 Apr 2016 12:28:10 +0200 Received: from 217.10.52.10 ([217.10.52.10]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Apr 2016 12:27:59 +0200 Received: from Stromeko by 217.10.52.10 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Apr 2016 12:27:59 +0200 To: cygwin@cygwin.com From: Achim Gratz Subject: Process map and fork problems Date: Wed, 20 Apr 2016 10:38:00 -0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00491.txt.bz2 I'm chasing a problem on some 32bit Windows installs that supposedly happened after one of the Windows updates (and probably other software updates) in the last few months (the affected users were unable to pin it down further unfortunately). It's obviously caused by two heap sections in the process map that are smack dab in the middle of the address range used by rebase: 20000000-200A0000 rw-p 00000000 0000:0000 0 [heap] 200A0000-38000000 ===p 000A0000 0000:0000 0 [heap] These do not exist on 32bit Cygwin installs on 64bit Windows installations, so I couldn't see these problems on my test machine. If I rebase the colliding DLL manually out of this region, things start to work again. Is there any way to find out where these come from? The address range seems to be fixed so far, so I probably could have rebase skip this range, but I'd rather move these out of the way if possible. Regards, Achim. -- 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