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?

Corinna Vinschen writes:

> > 
> > 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.
Oops - I thought running rebaseall AND peflagsall is recommended on a win7/64 

I just installed a full cygwin installation (without games/gnome/kde/audio) in 
another directory (please note: no snapshot installed) and did the follwing 
for testing how many dlls have ASLR bit set:

$find . -iname '*.dll' | xargs peflags -v 2>/dev/null | grep '+dynamicbase' | 
wc -l

[fresh installation]
77 (is this OK?)

[old installation with peflagsall run]

1450 DLLs !!! so perhaps this is real problem.

But what's about the other possible problem: tsawareness?
Should I set tsware for the DLLs - we always use remote desktop for connecting 
to other windows machines - so tsware should be set?
Is this correct?

What's the best to reinstall our system, cause I really not know which dll 
should have set dynamicbase or not?
Use cygwin setup option REINSTALL or remove installation and INSTALL?

> 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.
I know the new feature of rebase (nice feature) ...
I checked this already - there are no asterisks.

> 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.

I know /proc/$PID/maps - nice feature too.

This sounds good, but is there a way doing this programatically - in an easy 
Cause only delaying will not work - cause the error is runing on a remote 
machine ...
Or even prettier - print the name of the dll which uses the address space with 
using the /proc/$PID/maps contents.
I think this will be really helpfull for other users who have such an error.
This perhaps in combination with an environment setting in the CYGWIN variable 
would be really great feature.

Or is there an easy way for me to suspend the thread running into this error?
So I can start another shell for looking into /proc/$PID/maps.

I'm sorry - I'm really not an expert in cygwin programming ...
Perhaps you can give me a hint for suspending the thread/process?

Best regards


Problem reports:
Unsubscribe info:

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