Mail Archives: cygwin/2012/02/06/04:24:18
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
process.
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
- Raw text -