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
>
>
> 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:
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_
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
>>
(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
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
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
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.
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-
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
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
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
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
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
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
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
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
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
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
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
***
[...]
* 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
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
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,
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
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
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
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,
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
28 matches
Mail list logo