X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE
X-Spam-Check-By:	sourceware.org
Message-ID:	<4F33C827.6020905@dronecode.org.uk>
Date:	Thu, 09 Feb 2012 13:20:39 +0000
From:	Jon TURNEY <jon DOT turney AT dronecode DOT org DOT uk>
Reply-To:	cygwin AT cygwin DOT com
User-Agent:	Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: perl fork error: child_info_fork::abort: data segment start: - example code!
References:	<loom DOT 20120208T143015-651 AT post DOT gmane DOT org> <20120208142712 DOT GK25129 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20120208142712.GK25129@calimero.vinschen.de>
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

On 08/02/2012 14:27, Corinna Vinschen wrote:
> On Feb  8 13:59, Heiko Elger wrote:> 
>> Yes - I know it is a BLODA - but please go  on reading - my company want to 
>> contact Symantec cause of these ERRORs.
>>
>> The following simple perl script will produce the following error:
>> ***** snip snip snip ***
>> [...]
>> ********* snip snip snip ****************
>>
>> 1.)
>> Symantec is installed and is running but it is complete deactivated with 
>> context menu.
>> What does this error mean - please a little bit in delail?
>> 0 [main] perl 8916 child_info_fork::abort: data segment start: parent
>> (0xC1A000) != child(0xA6A000)
> 
> The code checks if the data and bss segments of a given DLL, which was
> already loaded by the parent process, is in the same spot in the child
> process.  If not, the DLL has been loaded into another address in the
> child, which will likely result in a nonfunctional forked process.

It seems to me that what this error actually means is that we correctly
located the DLL in step 2 of load_after_fork(), but then we actually tried to
load it for real in step 3, it landed in the wrong place (which
dll_list::alloc() detects and reports)

> Perhaps.  Probably.  I'm not sure.  However, the above addresses
> 0xC1A000 and 0xA6A000 are *very* unlikely DLL load addresses in a
> Windows system.  Usually DLLs are loaded at addresses beyond
> 0x10000000, preferredly to the address stored in the DLL header.
> As I said , I don't no if SEP is really the culprit here, but at
> least the address are weird.  And...

It seems to be perfectly normal for DLLs to get relocated below 0x1000000 on
my XP SP3 system.

--
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

- Raw text -