X-Recipient: archive-cygwin@delorie.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 Reply-To: cygwin@cygwin.com User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: perl fork error: child_info_fork::abort: data segment start: - example code! References: <20120208142712.GK25129@calimero.vinschen.de> In-Reply-To: <20120208142712.GK25129@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.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