X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-0.8 required=5.0 tests=AWL,BAYES_00,RCVD_NUMERIC_HELO,SARE_SUB_ENC_UTF8,SPF_HELO_PASS,T_RP_MATCHES_RCVD
X-Spam-Check-By:	sourceware.org
To:	cygwin AT cygwin DOT com
From:	Heiko Elger <heiko_elger AT arburg DOT com>
Subject:	Re: perl fork error: =?utf-8?b?Y2hpbGRfaW5mb19mb3JrOjphYm9ydDo=?= data segment start: - example code!
Date:	Wed, 8 Feb 2012 14:55:56 +0000 (UTC)
Lines:	35
Message-ID:	<loom.20120208T154403-845@post.gmane.org>
References:	<loom DOT 20120208T143015-651 AT post DOT gmane DOT org> <20120208142712 DOT GK25129 AT calimero DOT vinschen DOT de>
Mime-Version:	1.0
User-Agent:	Loom/3.14 (http://gmane.org/)
X-IsSubscribed:	yes
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

Corinna Vinschen writes:

> > So why I will get this error - only cause of symantec?
> 
> 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...

Is this perhaps same problem or a side effect as discussed in in 
http://thread.gmane.org/gmane.os.cygwin/131027/focus=131095?

So I think SEP will install hook DLLs - regardeless SEP is active or inactive.
And if dll loading is done via native cygwin and loaded again for forking 
perhaps it's real name normalize by SEP is different to the already loaded 
name by cygwin.

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

Can you tell me where this checking is done.
So I can instrument it in same way as last time ... 
or like in http://thread.gmane.org/gmane.os.cygwin/131027/focus=131095.

I think it's not the same code - using full dll name rather than just the 
basename od the dll.

best regards

Heiko



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