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 the
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
8
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
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
http://cygwin.com/ml/cygwin/2012-02
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: addr
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,
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, bec
rors while
running perl script!
But I know there are address overlaps in the DLLs (this is why rebaseall 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:
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.
> >
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
>
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
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
>
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 an
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/registr
day 2012-02-01.
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 E
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
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 f
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: ht
Christopher Faylor >
> >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
Heik
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 semicolo
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: http://cygwin
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/s
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
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
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.
\??\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/
Document
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
script
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 w
marco atzeri
> 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 am currently
elayed?
I noticed in http://article.gmane.org/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
gure my syslogd - 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 r
seall and peflagsall.
rebaseall was patched 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 so
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?
> &g
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
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
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, an
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"
> > >Bu
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. Fayl
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,
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,
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 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,
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 f
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 fr
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
you have to run this script a long time.
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
mounts v2
Cygdrive flags: 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
---
total 0
drwxr-xr-x+ 2 heikoKein0 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_
48 matches
Mail list logo
