Re: perl fork error: child_info_fork::abort: data segment start: - example code!

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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