This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: extremely rarely fork errors: who occuppies the space?

On Feb  6 06:42, Heiko Elger wrote:
> Hello,
> our current system is the following (cygwin installation is nearly up to date).
> $ uname -a
> CYGWIN_NT-6.1-WOW64 PCFX163 1.7.10s(0.259/5/3) 20120111 22:39:26 i686 Cygwin
> some systems uses a newer snapshot:
> uname -a
> CYGWIN_NT-6.1-WOW64 PCFX061 1.7.10s(0.259/5/3) 20120202 16:59:00 i686 Cygwin
> We've still some not reproduceable fork errors like the following
>       0 [main] sh 90024 child_info_fork::abort: address space needed 
> by 'cygiconv-2.dll' (0x6D0D0000) is already occupied
>       7 [main] sh 88036 child_info_fork::abort: address space needed 
> by 'cygiconv-2.dll' (0x6D0D0000) is already occupied
> The error is extremely rarely - perhaps just once a day
> Antivirus software is deinstalled, Windows defender is deactivated.
> Rebaseall and peflagsall were running.

YoU don't need to run peflags.  If you have set the ASLR flag, it could
be the culprit.  Try resetting it and, I think, reboot the machine.  As
far as I understand ASLR on Windows, it stores rebase addresses for DLLs
in a database and always uses the same values until reboot.

As for rebaseall, are you really sure?  You can inspect the values the
Cygwin DLLs are rebased to by running `rebase -s -i'.  If the output
contains asterisks after the base and size values of two adjacent DLLs,
they collide and need rebasing again.

> We have this error really not reproduceable on some compile machines.
> These machines are running a perl script which polls a remote database for 
> running make jobs in parallel (-j flag) - that's all.
> Normally all works fine - but sometimes we got these fork errors.
> Is there an possibility to get more information who is occupying the address 
> space?
> Perhaps I can instrument the cygwin1.dll to wait or do something special - so 
> I can use other tools i.e. sysinternals vmmap, process explorer ...
> to have a look who is using this address space.
> Perhaps a self build debug snapshot version with instrumented debug flags will 
> give me some hints?

For a start, you could use the shiny new /proc/$PID/maps functionality
on the parent shell.  If you have a shell which fails to fork and you
can get it to wait, then fetch the pid from ps and call `less
/proc/$PID/maps' and see what is at 0x6d000000.  If you want to stop
the child, you would have to build your own Cygwin DLL and add something
like a long Win32 Sleep() call after printing the above message in
child_info_fork::abort and then look into /proc/$PID/maps for that


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]