Re: Random "child_info_fork::abort:"

2016-10-15 Thread Evgeny Grin
On 15.10.2016 1:58, Tony Kelman wrote: >> 2 [main] mandb (736) t:\cygwin64\bin\mandb.exe: *** fatal error - >> cygheap base mismatch detected - 0x1802FC408/0x110C408. > > As far as I can tell, build 14946 fixed whatever the problem was. > Crisis averted, for now. > > -Tony > >

Re: Random "child_info_fork::abort:"

2016-10-14 Thread Tony Kelman
>  2 [main] mandb (736) t:\cygwin64\bin\mandb.exe: *** fatal error - > cygheap base mismatch detected - 0x1802FC408/0x110C408. As far as I can tell, build 14946 fixed whatever the problem was. Crisis averted, for now. -Tony -- Problem reports: http://cygwin.com/problems.html FAQ:

Re: Random "child_info_fork::abort:"

2016-10-13 Thread Evgeny Grin
On 13.10.2016 19:58, Evgeny Grin wrote: > On 13.10.2016 18:24, Evgeny Grin wrote: > > What I got from strace (typical output): > > 649705 [main] mandb 6288 child_info::sync: n 2, waiting for > subproc_ready(0x280) and child process(0x1CC) >6358 [main] mandb 7888 child_

Re: Random "child_info_fork::abort:"

2016-10-13 Thread Evgeny Grin
wrote: >>>>>> I'm using Windows Insider (slow ring, prerelease). After recent update >>>>>> to build 14931, cygwin keeps randomly fail on fork. This happens not >>>>>> every fork, but frequent enough. Simplest way to trigger it is to run >>

Re: Random "child_info_fork::abort:"

2016-10-13 Thread Evgeny Grin
(slow ring, prerelease). After recent update >>>>> to build 14931, cygwin keeps randomly fail on fork. This happens not >>>>> every fork, but frequent enough. Simplest way to trigger it is to run >>>>> mandb. >>>>> At variable delay I got somethi

Re: Random "child_info_fork::abort:"

2016-10-13 Thread Brian Inglis
On 2016-10-13 06:31, Eliot Moss wrote: On 10/13/2016 8:00 AM, Marco Atzeri wrote: On 13/10/2016 09:11, Evgeny Grin wrote: MS is pushing us to "Ubuntu on Windows"? Interesting. Are we back to the old tactics ? https://en.wikipedia.org/wiki/AARD_code I don't see the motivation. We still buy

Re: Random "child_info_fork::abort:"

2016-10-13 Thread Eliot Moss
On 10/13/2016 8:00 AM, Marco Atzeri wrote: On 13/10/2016 09:11, Evgeny Grin wrote: MS is pushing us to "Ubuntu on Windows"? Interesting. Are we back to the old tactics ? https://en.wikipedia.org/wiki/AARD_code I don't see the motivation. We still buy Windows. Do you think they'll

Re: Random "child_info_fork::abort:"

2016-10-13 Thread Marco Atzeri
On 13/10/2016 09:11, Evgeny Grin wrote: Additionally tested under VM. Clear install of Windows 10 x64 14931 (US English), VM guest tools and Cygwin x64. First run of man-db - same error. Need new workarounds? Seems that will be in all new builds. Same happens with new Windows build 14942.

Re: Random "child_info_fork::abort:"

2016-10-13 Thread Evgeny Grin
to build 14931, cygwin keeps randomly fail on fork. This happens not >>>> every fork, but frequent enough. Simplest way to trigger it is to run >>>> mandb. >>>> At variable delay I got something like >>>> child_info_fork::abort: T:\cygwin64\bin\cygman-2-

Re: Random "child_info_fork::abort:"

2016-10-12 Thread Evgeny Grin
happens not >>> every fork, but frequent enough. Simplest way to trigger it is to run >>> mandb. >>> At variable delay I got something like >>> child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to >>> different address: parent(0x3FEAB) != child

Re: Random "child_info_fork::abort:"

2016-10-12 Thread Evgeny Grin
mplest way to trigger it is to run >> mandb. >> At variable delay I got something like >> child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to >> different address: parent(0x3FEAB) != child(0x1C) >> Dll name and child address may vary. >> I updated

Re: Random "child_info_fork::abort:"

2016-10-12 Thread Brian Inglis
child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to different address: parent(0x3FEAB) != child(0x1C) Dll name and child address may vary. I updated cygwin to latest version, but problem remains. Exactly the same problem with Msys2, but additionally from time to time I got

Random "child_info_fork::abort:"

2016-10-11 Thread Evgeny Grin
Hi! I'm using Windows Insider (slow ring, prerelease). After recent update to build 14931, cygwin keeps randomly fail on fork. This happens not every fork, but frequent enough. Simplest way to trigger it is to run mandb. At variable delay I got something like child_info_fork::abort: T:\cygwin64

child_info_fork::abort:

2012-06-11 Thread Rodrigo Botafogo
     0 [main] ruby 8140 child_info_fork::abort: address space needed by 'cygnetcdf-7.dll' (0x42) is already occupied      0 [main] ruby 6960 child_info_fork::abort: address space needed by 'cygnetcdf-7.dll' (0x42) is already occupied      0 [main] ruby 5692 child_info_fork::abort

Re: child_info_fork::abort:

2012-06-11 Thread Ryan Johnson
On 11/06/2012 9:49 AM, Rodrigo Botafogo wrote: Ryan, Thanks also for your reply. In your reply you say that if the system has a very large number of DLL rebase might not work. Just for curiosity, what is a large number of DLL? When do I run a risk of having problems with rebaseall? Short

child_info_fork::abort:

2012-06-05 Thread Rodrigo Botafogo
I´m using the latest cygwin distribution 1.7.15-1 and I´m using Ruby with netcdf.  I keep on getting the following messages:       0 [main] ruby 8140 child_info_fork::abort: address space needed by 'cygnetcdf-7.dll' (0x42) is already occupied       0 [main] ruby 6960 child_info_fork::abort

Re: child_info_fork::abort:

2012-06-05 Thread Ryan Johnson
On 05/06/2012 11:45 AM, Rodrigo Botafogo wrote: I´m using the latest cygwin distribution 1.7.15-1 and I´m using Ruby with netcdf. I keep on getting the following messages: 0 [main] ruby 8140 child_info_fork::abort: address space needed by 'cygnetcdf-7.dll' (0x42) is already occupied

Re: child_info_fork::abort:

2012-06-05 Thread marco atzeri
On 6/5/2012 5:45 PM, Rodrigo Botafogo wrote: I´m using the latest cygwin distribution 1.7.15-1 and I´m using Ruby with netcdf. I keep on getting the following messages: 0 [main] ruby 8140 child_info_fork::abort: address space needed by 'cygnetcdf-7.dll' (0x42) is already occupied

0 [main] svn 3288 child_info_fork::abort: address space needed by 'cygsasldb-2.dll' (0x3D0000) is already occupied

2012-02-19 Thread Anders Broman
Hi, Since updating to 1.7.10 I can't use SVN, tried the latest snapshot too. $ svn up Updating '.': 0 [main] svn 3288 child_info_fork::abort: address space needed by 'cygsasl db-2.dll' (0x3D) is already occupied svn: E11: Unable to connect to a repository at URL 'svn+ssh://x

Re: 0 [main] svn 3288 child_info_fork::abort: address space needed by 'cygsasldb-2.dll' (0x3D0000) is already occupied

2012-02-19 Thread marco atzeri
On Mon, Feb 20, 2012 at 8:01 AM, Anders Broman wrote: Hi, Since updating to  1.7.10 I can't use SVN, tried the latest snapshot too. $ svn up Updating '.':      0 [main] svn 3288 child_info_fork::abort: address space needed by 'cygsasl db-2.dll' (0x3D) is already occupied svn: E11

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

2012-02-09 Thread Jon TURNEY
*** [...] * 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

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

2012-02-09 Thread Corinna Vinschen
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

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

2012-02-09 Thread Heiko Elger
Corinna Vinschen writes: 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) Hello,

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

2012-02-09 Thread Corinna Vinschen
On Feb 9 14:50, Heiko Elger wrote: Corinna Vinschen writes: 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

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

2012-02-08 Thread Heiko Elger
of these ERRORs. The following simple perl script will produce the following error: * snip snip snip *** $ ./forktest.pl start 0 [main] perl 8916 child_info_fork::abort: data segment start: parent (0xC1A000) != child(0xA6A000) Error beim fork() Parent:Code at end... * snip snip snip

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

2012-02-08 Thread Corinna Vinschen
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

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

2012-02-08 Thread Heiko Elger
Corinna Vinschen writes: So why I will get this error - only cause of symantec? 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 0x1000,

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

2012-02-08 Thread Corinna Vinschen
On Feb 8 14:55, Heiko Elger wrote: Corinna Vinschen writes: So why I will get this error - only cause of symantec? 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