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
