On Feb 9 13:20, Jon TURNEY wrote: > 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.
Indeed? Well, the problem here is that the DLL has already been rebased to 0xC1x000 in the parent process. Unless the DLL start address in the file header is set to that address. If so, that's quite a problem, because the memory area with, let's say, 6 digit hex addresses is rather thickly populated in every process. Apart from the default stack which is usually somewhere up to 0x230000 and the application image at 0x400000 there's the Win32 default application heap and other heaps created by Win32 DLLs. So, in the above scenario the question is why has the WIndows loader put the DLL to 0xC1x000 in the first place? I changed the debug output for this scenario in the latest snapshot, something along the lines of child_info_fork::abort: C:\cygwin\cygsome.dll: Loaded to different address: parent(0xA00000) != child(0xB00000) So with the latest snapshot we can at least see which DLL is affected by this problem. Then we can check where this DLL is really supposed to be in memory (objdump -h) and then we can check what really is at this location in the process VM (/proc/$PID/maps) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
