I can agree having some times same error on multiple machines (win7/64) - but
always when running perl.
1 [main] perl (7796) c:\programme\cygwin\bin\perl.exe: *** fatal error -
cygheap base mismatch detected - 0xE158D0
/0xEF58D0.
This problem is probably due to using incompatible versions of
Hallo,
Im using a nearly upto date cygwin installation with the following
snapshot.
$ uname -a
CYGWIN_NT-6.1-WOW64 PCFX162 1.7.11s(0.259/5/3) 20120209 16:18:27 i686 Cygwin
I got once the following error on the console:
0 [main] sh 85464! _pinfo::dup_proc_pipe: something failed for pid 0: res
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,
is
recommended).
Can some reproduce same or similar errors.
Please help.
Any hints are welcome.
Heiko Elger
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http
Corinna Vinschen writes:
What happens in this testcase is that Cygwin checks the full DLL path
and then finds that the new path to cyggcc_s-1.dll is not the same as
the path it has already loaded. Therefore it assumes that it has to add
the file to list.
This is plainly wrong, because,
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,
Denis Excoffier writes:
Here it is. Enjoy!
1 [main] gcc-4 5440 dll_list::reserve_space: address space needed
by 'cygiconv-2.dll' (file
D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygiconv-2.dll) (0x674C with
type 1=DLL_LINK)
1580 [main] gcc-4 5440 dll_list::reserve_space: address
marco atzeri writes:
See
http://cygwin.com/faq.html
at
4.44. How do I fix fork() failures?
and related
/usr/share/doc/rebase/README
Just one question to this point.
I know all this documentation - but I was pointed by C. Vinschen in
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
Corinna Vinschen writes:
On Feb 6 11:00, Heiko Elger wrote:
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
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
Hello,
I'm using latest snapshot and all installed cygwin packages are up to date.
All categories except KDE, GNOME, AUDIO and GAMES are installed.
$ uname -a
CYGWIN_NT-6.1-WOW64 PCFX061 1.7.10s(0.259/5/3) 20120201 05:28:17 i686 Cygwin
And I've installed an build some CPAN modules.
rebaseall
Corinna Vinschen writes:
On Feb 2 09:56, Corinna Vinschen wrote:
I've created a new snapshot 2012-02-02. Can you please test it? AFAICS
I got rid of the memory leak. A recent change broke the fdopendir
handling entirely, apparently. I tested it with a full `find /' scan and
I
checked this at home on my two private computers running Win XP and Win7
Ultimite (non 64bit version) with snapshot 2012-01-23
and I cannot reprodue the error.
So perhaps it seems to be a 64bit problem!
Can anyone agree reproducing same problem?
With best regards
Heiko Elger
--
Problem reports
Corinna Vinschen writes:
This looks like a problem when recursing over the /proc/registry and
it doesn't look like a 64 bit problem. I'll have a look.
I saw same problem runing find command i.e. /cygdrive/c/Programme/cygwin (root
of my cygwin installation) ad there is no /proc/registry.
Dave Korn gmail.com writes:
looks like there was a second snapshot later the same day that replaced the
one you had installed.
That's it! Thanks a lot ..
I never see a snapshot released twice a day
Just one question:
How can I figure out whether a snapshot is released more than once a
Christopher Faylor writes:
If you are saying that the problem is not fixed in the most recent
snapshot then please clearly say that. Otherwise, I don't understand
what you are asking. I sent my email on January 11 shortly before the
January 11 snapshot was uploaded. There is no reason for
Christopher Faylor writes:
? The snapshot that I was referring to was created shortly after my
above email went out.
oops - but the only snapshot I see on the cygwin page
http://cygwin.com/snapshots/ is dated 20120111.
I cannot see a newer snapshot?
Heiko
--
Problem reports:
Christopher Faylor writes:
No need to answer that. The upcoming snapshot should fix the problem.
I forgot to say: Thanks for the simple test case. Those are always
much appreciated.
thanks a lot for your great work.
Is it possible to create a new snapshot til monday?
best regards
Hello,
I'm using latest snapshot and updated cygwin installation.
$ uname -a
CYGWIN_NT-6.1-WOW64 PCFX166 1.7.10s(0.259/5/3) 20120111 01:45:50 i686 Cygwin
I've done rebaseall and peflagsall.
I've found the following problem using make in parallel (-j) with multiple
commands joined with
I can agree all works fine ...
good job
I wish all a Merry Christmas and a Happy New Year.
Heiko
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
Chris Sutcliffe writes:
Tested with the 20111218 snapshot and the vim build now fails with as
a result of a different issue:
make[1]: *** read jobs pipe: Resource temporarily unavailable. Stop.
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory `/usr/src/vim/src'
Hello,
I spend much of time in reproducing a testcase - I hope that this problem can
be reproduced by others too.
While looking for a testcase for reproducing our other problem with Bad
address errors - I tried to build cygwin snapshot 20111213.
I did a fresh cygwin intallation for this test.
Christopher Faylor writes:
It's easy to reproduce. It's the result of changes I made in recent
snapshots
to handle signals in threads.
that sounds good.
Is it easy to fix it!
Is it fixed in latest snapshot 20111214?
I read somthing about signal handling in ChangeLog.
regars
Heiko
Heiko Elger writes:
Christopher Faylor writes:
It's easy to reproduce. It's the result of changes I made in recent
snapshots
to handle signals in threads.
that sounds good.
Is it easy to fix it!
Is it fixed in latest snapshot 20111214?
I tested it - still same issue
(\??\V:\Stg_V5.108_ente59_iv\stg2\steuerung\makefile)
by name works
NtQueryFullAttributesFile(\??\V:\Stg_V5.108_ente59_iv\stg2\steuerung\makefile)
by handle works
regards
Heiko Elger
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq
Hello,
I upgrade from snapshot 20110829 to current 20111208 qand I update the tools
too.
$ uname -a
CYGWIN_NT-6.1-WOW64 PCFX167 1.7.10s(0.255/5/3) 20111208 06:50:31 i686 Cygwin
I did rebaseall and peflagsall.
I got some Bad address errors while compiling with make while running shell
Hello,
I'm using latest setup version 2.761.
$ uname -a
CYGWIN_NT-6.1-WOW64 PCFX061 1.7.10s(0.255/5/3) 2029 17:41:48 i686 Cygwin
I've done a setup at end of august in unattended mode with the
following call of setup, I added all categories except Audio,Games,
Gnome and KDE. All categories
- or is it not possible to log these
kind of errors.
My syslog.conf file has only one entry.
* snip sni snip *
*.* /var/log/messages
* snip sni snip *
Any help welcome.
I'm sorry - but I use syslogd the first time.
best regards
Heiko Elger
/gmane.os.cygwin/129594 that there is an
existing error - so I will give the the next snapshot a try.
@cfg:
Can this http://article.gmane.org/gmane.os.cygwin/129594 the reason for our
problems too?
Any hints are welcome.
best regards
Heiko Elger
--
Problem reports: http://cygwin.com
marco atzeri marco.atzeri writes:
Heiko,
you wrote a lot of mail , but I do not remember a single
Problem reports: http://cygwin.com/problems.html
As cygwin is working on win7/64, something is wrong on your machine,
but until you provide clear data we can not easly help you.
I
to ignore files in /usr/x86_64-w64-mingw32/sys-
root/mingw/bin.
But it seems something is still wrong.
All other found postings concerning this problem described that doing a
rebaseall/peflagsall will solve thies problems.
Perhaps other user can give me some more hints.
best regards
Heiko
Christopher Faylor writes:
On Thu, Aug 11, 2011 at 05:07:15AM +, Heiko Elger wrote:
Ryan Johnson writes:
Let me ask again, what was being compiled when the problems arose? And
is it an intermittent error or a consistent one?
I'm sorry - I havn't seen your question
Christopher Faylor writes:
On Wed, Aug 10, 2011 at 04:51:32AM +, Heiko Elger wrote:
Hello,
I know there are lots of such postings Resource temporarily unavailable.
But using lates snapshot (2011-08-03): there are changes by C. Faylor
printing
cause of fork failure.
I can see I'm
Heiko Elger writes:
Christopher Faylor writes:
On Wed, Aug 10, 2011 at 04:51:32AM +, Heiko Elger wrote:
Hello,
I know there are lots of such postings Resource temporarily unavailable
But using lates snapshot (2011-08-03): there are changes by C. Faylor
printing
cause
Ryan Johnson writes:
Did you reboot? Windows won't notice the changes made by peflagsall
until you do so.
yes
Also, you never mentioned what you are making. Are you, by chance
building an app which builds helper binaries and/or lots of shared
libraries? Apps such as emacs, gcc, and
Ryan Johnson writes:
Let me ask again, what was being compiled when the problems arose? And
is it an intermittent error or a consistent one?
I'm sorry - I havn't seen your question.
The error is intermittent.
Sometimes I have this error and sometimes not - really not reproduceable.
If it
Rob Walker writes:
You could also use a patched make 3.81 compiled for Cygwin 1.7.
http://sites.rwalker.com/cygwin/
I saw your ports already.
One question to them: why are the executables so large?
The original make-3.81 (cygwin-1.7) is really small.
$ ls -l make-*
-rwxr-xr-x 1 ente59
Hello,
I know there are lots of such postings Resource temporarily unavailable.
But using lates snapshot (2011-08-03): there are changes by C. Faylor printing
cause of fork failure.
I've gotten the following error message while running make in parallel
using (make -j8).
0 [main] sh 8
Hello,
cause of colon problems we have to use old make version 3.80 in cygwin 1.7.x.
The binary make.exe is a copy of cygwin 1.5.x installation.
Is it correct to use this version within cygwin 1.7.x?
Or do I have to rebuild the binary?
At the moment all seems to work fine - I only want to avoid
Hello jojelino,
I just rebuild cygwin1.dll latest snapshot.
I believe the attached patch workarounds delayed wait_sig problem.
Yes - it works fine!
This yielded speed improvement. i ran your testcase and same timestamp
recorded 35. approx 2x speed.
Hello,
Corinna Vinschen writes:
The slowdown of the code was the result of a patch which was supposed
to fix a potential race condition. Jojelino's patch looks nice, but
it might reintroduce a new race. Handle with care.
Oops - what king of race condition do you mean.
OK - that's a new
Hello,
next time we will change our PC's from Intel Core2 Quad Core Q9550 WinXP/32 SP3
to Xeon E31275 WIN7/64 SP1.
At the moment I test the performance of our make system with cygwin 1.7-9 latest
snapshot from 2011-07-21.
I notice a very performance degree in starting/forking other executables
Mark Geisert writes:
Please don't quote raw email addresses; not quoting these is a list
convention.
I'm sorry ...
shell script:
*** snip snip snip
1 [main] bash 4800 fork: child -1 - CreateProcessW failed for
'c:\programme\cygwin\bin\bash.exe', errno 12
./test2.sh: fork:
Mark Geisert writes:
int main(int argc, char** argv[])
(I won't point out the error in the above line.)
Oops ...
The good news is that I was then able to reproduce the issue without Cygwin.
OK - I was able to reproduce the issue too
After 15 minutes, peak memory usage had gone from
.
Best regards
Heiko Elger
--
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
: cygdrive flags
Cygdrive prefix: cygdrive prefix
Cygdrive default prefix:
Build date: Wed Dec 25 15:37:50 EST 2002
Shared id: cygwin1S3
- Linux: Suse 8.1
Perhaps someone can give me a hint ...
Best regards
Heiko Elger
snip - snip - snip
0 Dec 15 19:02 distcc_03eb
$ ls -l /tmp/distcc_03eb/
total 0
-rw---1 heikoKein0 Dec 15 19:02
lock_localhost_000
-rw---1 heikoKein0 Dec 15 19:02
lock_localhost_001
Heiko Elger
48 matches
Mail list logo
