Re: cygheap base mismatch detected
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 cygwin DLL. Search for cygwin1.dll using the Windows Start->Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. I see this error using 1.7.9 (nearly all baselines till 1.7.10) and 1.7.10 1.7.11 not yet tested). I the error occured once - I can reproduce is running simple perl script in bash like the following: perl -e 'print "hello\n";' I checked our installation: There is really only one cygwin installation on it. This is the last issue after all for issues we've had. I've hoped this will be solved in 1.7.11 - I read something about increasing heap space (in a 1.7.11 snapshot I think). What we really have is the following - so perhaps cygwin thinks he will file multiple cygwin1.dll files. We are using German Win7/64. Cygwin is installed into c:\Programme\cygwin. In German Win7 c:\Programme is a system link to "c:\Program Files" - this is by Win7 automatically. Our IT departement create a junction c:\Programme to "c:\Program Files" using mklink /J c:\Programme "c:\Program Files" - cause of other older incompatabilities to our old WinXp environment having a real c:\Programme directory. I'm not sure - but perhaps cause of this - cygwin will came into trouble. @Charles: where is your main installation directory of cygwin. I suppose you've not running a German Win7 installation! Is there a way of instrumentation for this error to get even more information? Can anyone give me a hint - what the real problem for this is! Heap corruption? Too small heap? Wrong DLL loaded at wrong base address? best regards. Heiko -- 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
console message: _pinfo::dup_proc_pipe: something failed for pid 0 ...
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 85464, hProcess 0x158, wr_proc_pipe 0xD8 vs. 0xD8, Win32 error 5 Can anyone tell me what's going wrong? The error was echoed while running a perl script which polls our database for compile jobs for our project build system (running make). I found the error in our make.log file. But cause of running make in parallel (-j8) - it's not clear which command produces this error: sh, gcc or perl !?! The make system will not abort cause of error - so I'm really not sure - is it an error, a warning or just an information? I never have seen such an error before using snapshot 20120209. best regards Heiko -- 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
Re: perl fork error: child_info_fork::abort: data segment start: - example code!
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,
I instrumented dll_list::alloc() a little bit - a now we will see the
following.
New code from Corinna and some other code ...
$ ./forktest.pl
start
0 [main] perl 8424 dll_list::alloc: alloc() - Error
396 [main] perl 8424 dll_list::alloc:
C:\PROGRAMME\CYGWIN1710MINIMAL\bin\cygperl5_10.dll: Loaded to different
address: parent(0xC4) != child(0xB8)
1116 [main] perl 8424 dll_list::alloc: data segment start: parent
(0xD7A000) != child(0xCBA000)
1240 [main] perl 8424 dll_list::alloc: data segment end: parent(0xD991E0) !
= child(0xCD91E0)
1350 [main] perl 8424 dll_list::alloc: bss segment start: parent(0xD9C000) !
= child(0xCDC000)
1461 [main] perl 8424 dll_list::alloc: bss segment end: parent(0xD9C610) !=
child(0xCDC610)
1538 [main] perl 8424 dll_list::alloc: Long Sleep: 1h
1599 [main] perl 8424 dll_list::alloc: Sleep 100s
With sysinternal tool vmmap I see the correct addresses of cygperl5_10.dll of
the parent perl process (BSS and DATA)
Using vmmap for the forked perl process is not possible - utility hangs -
perhaps cause of hanging process?!?
Similar problem looking into /proc/PID/map
Why is this wrong mapping done?
I figured our the following:
Using SEP there is a service running called sysplant ("Application and Device
Control", system32\Drivers\SysPlant.sys).
Disabling this service on cmd line (cmd.exe)
sc config sysplant start= disabled
rebooting all seems to work fine!
I will contact Symantec for more details about this service.
The output of objdump -h is the following:
$ objdump -h cygperl5_10.dll
cygperl5_10.dll: file format pei-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 001386fc 57011000 57011000 0400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 0001f1e4 5714a000 5714a000 00138c00 2**5
CONTENTS, ALLOC, LOAD, DATA
2 .rdata0780 5716a000 5716a000 00157e00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .eh_frame 0004 5716b000 5716b000 00158600 2**2
CONTENTS, ALLOC, LOAD, DATA
4 .bss 0610 5716c000 5716c000 2**5
ALLOC
5 .edatadcd0 5716d000 5716d000 00158800 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .idata1a08 5717b000 5717b000 00166600 2**2
CONTENTS, ALLOC, LOAD, DATA
7 .reloc8818 5717d000 5717d000 00168200 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .gnu_debuglink 0014 57186000 57186000 00170c00 2**2
CONTENTS, READONLY
What is the recommended address layout?
Should DATA be mapped to 0x5714a000 and BSS to 0x5716c000?
Well - I just do the test again with disabled Symantec sysplant service.
... and ... voila ...
Verifying address layout is:
cygperl5_10.dll is loaded at address 0x5071 and all addresses shown with
objdump -h
are used!
That's really fine ...
Thanks a lot Corinna and all others
best regards
Heiko
--
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
Re: v1.7.10 -- forked process died unexpectedly
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/msg00092.html not to use peflagsall. I know all the tools - rebase, rebaseall, peflags, peflagsall, perlrebase. They should be used when having fork failures. What's the correct way of using these tools. I know - I have to use rebaseall to resolve address layout conflicts! This is really clear and it has to be run. But what's about peflagsall - setting dynamicebase (ASLR) for DLLs. And whats about perlrebase? It uses another lower! address space and put perl and all perl related DLLs together in this address space and is removing dynamicbase (ASLR) for these DLLs. So - this all together is confusing me ... Can you tell me your opinion. best regards Heiko -- 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
Re: cygwin-1.7.10-1 fork - address space needed by ... already in use
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 space needed by 'cygintl-8.dll' (file > D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C with type 1=DLL_LINK) >1899 [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 2=DLL_LOAD) >2562 [main] gcc-4 5440 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (file > \\?\D:\Home\dexcoff1\dexcoff1\cygwin2011f\bin\cygintl-8.dll) (0x6F5C with type 2=DLL_LOAD) >3290 [main] gcc-4 5440 child_info_fork::abort: address space needed by 'cygiconv-2.dll' (0x674C) > is already occupied > 2 [main] gcc 3408 fork: child -1 - forked process died unexpectedly, retry 0, exit code 1, errno 11 > Hello Denis, thanks a lot for your testing ... Is is possible to send me the snapshot patches responsible for this output. I solved my personal forked problem http://thread.gmane.org/gmane.os.cygwin/130982 - the problem was running peflagsall. But now I have a similar fork perl problem http://thread.gmane.org/gmane.os.cygwin/131091. To diagnose the problem a little bit deeper - perhaps your instrumented code will help. best regards Heiko -- 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
Re: perl fork error: child_info_fork::abort: data segment start: - example code!
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, preferredly to the address stored in the DLL header. > As I said , I don't no if SEP is really the culprit here, but at > least the address are weird. And... Is this perhaps same problem or a side effect as discussed in in http://thread.gmane.org/gmane.os.cygwin/131027/focus=131095? So I think SEP will install hook DLLs - regardeless SEP is active or inactive. And if dll loading is done via native cygwin and loaded again for forking perhaps it's real name normalize by SEP is different to the already loaded name by cygwin. > The code checks if the data and bss segments of a given DLL, which was > already loaded by the parent process, is in the same spot in the child > process. If not, the DLL has been loaded into another address in the > child, which will likely result in a nonfunctional forked process. Can you tell me where this checking is done. So I can instrument it in same way as last time ... or like in http://thread.gmane.org/gmane.os.cygwin/131027/focus=131095. I think it's not the same code - using full dll name rather than just the basename od the dll. best regards Heiko -- 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
Re: cygwin-1.7.10-1 fork - address space needed by ... already in use
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, as you can read on > http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx the > Windows loader does not load a DLL again, if it already has a module > loaded which has the same basename. Therefore the test for the full > pathname in Cygwin has to to be replaced with only testing the module > basename. > > However, while this situation in the doit2 testcase is simply explained, > I don't see how this affects your rsync call. > > Denis, can you please change your test output? Instead of printing only > d_alt->modname, please print d_alt->name and then run your rsync test > again. If this is the same problem as in the doit testcase, I'd like to > see where the second cygiconv-2.dll is coming from. In theory, if you > have only a single installation of cygiconv-2.dll, this should'nt > happen. Hello, just one more question concerning the problem of loading dlls twice. We installed cygwin into c:\Programme\cygwin 1) c:\programme is a symbolic link (like junction of sysinternal tools) to "c:\Program Files" via MKLINK /J and 2) c:\Programme is a WINDOWS7 language German localized link/substition/ or whatever to "c:\Program Files" too. Can this be a problem for cygwin too - concerning the problem of this thread? best regards Heiko -- 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
perl fork error: child_info_fork::abort: data segment start: - example code!
Hello all,
I'm using latest cygwin installation and snapshot 20120205.
$ uname -a
CYGWIN_NT-6.1-WOW64 PCFX061 1.7.10(0.259/5/3) 2012-02-05 12:36 i686 Cygwin
I run rebaseall and perlrebase!
As suggested by C. Vinschen in http://cygwin.com/ml/cygwin/2012-
02/msg00092.html I do not run peflagsall.
I know- running perlrebase - is only recommended using CPAN modules - in this
easy example there is no usage of CPAN but in other scripts we use CPAN.
We use Symantec Endpoint Protection 12.1.x!
Yes - I know it is a BLODA - but please go on reading - my company want to
contact Symantec cause 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 ***
This is the simple script.
* snip snip snip
$ cat forktest.pl
#!/usr/bin/perl -W
use strict;
print "start\n";
my $pid = fork();
if ( ! defined $pid)
{
print "Error beim fork()\n";
}
else
{
if ($pid)
{
print "Parent:Code ... - child PID=$pid\n";
print "Parent:Sleep 1 Sec\n";
sleep 1;
print "Parent:Sleep 1 Sec done\n";
}
else
{
print "Client:Code ...\n";
print "Client:Sleep 1 Sec\n";
sleep 1;
print "Client:Sleep 1 Sec done\n";
exit;
}
}
print "Parent:Code at end...\n";
* 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(0xA6A000)
So why I will get this error - only cause of symantec?
If uninstalling SEP all works fine.
2)
I installed a new cygwin in another directory.
I DO NOT rebaseall and perlrebase all seems to work fine - so no errors 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: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: extremely rarely fork errors: who occuppies the space?
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 > > > 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 > > system? > > No, that was a misunderstanding at one point. I thought this has been > removed from the relevant docs. That's possible - I cannot find this documentation now - but I'm really sure that I'd read this some months ago. > > > 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 > > > > 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? > > Yes and no. Only executables need this flag, it's ignored on DLLs. > And, gcc sets this flag by default since 4.3.4, so I think there's no > reason to use it anymore. Latest gcc 4.5.x also sets the large address > awareness flag on executables. Advantage of that flag: You get an > extra 2 Gigs of VM per process starting at 0x8000 on 64 bit systems. > Cygwin will put its application heap there, so you have more space in the > lower 2 Gigs for DLL rebasing. Oops - that was my personal error - I know tsawareness is set to EXE files only. > > > What's the best to reinstall our system, cause I really not know which dll > > should have set dynamicbase or not? > > None of it, actually. > > > Use cygwin setup option REINSTALL or remove installation and INSTALL? > > Just use peflags to remove the flag instead of reinstalling. I'm not > sure if some DLLs have this flag set by default in the distro, and in > that case you're back to square one and have to run peflags anyway. That's why I did counting dlls with dynamicbase flag already set - in a fresh installation. So over 77 dlls have set this flag. Or do you mean to remove the flag on really all DLLs? So - why do not REINSTALL/INSTALL? Are there any benefits - expect for the effort of time. Just two question beyond the scope of this posting: What's the best and easy way to duplicate a cygwin installation to 25 other machines? How to completely remove an cygwin installation includeing registry settings? best regards Heiko -- 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
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 system? 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 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 0x6d00. 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 way. 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 heiko -- 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
extremely rarely fork errors: who occuppies the space?
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 We've still some not reproduceable fork errors like the following 0 [main] sh 90024 child_info_fork::abort: address space needed by 'cygiconv-2.dll' (0x6D0D) is already occupied 7 [main] sh 88036 child_info_fork::abort: address space needed by 'cygiconv-2.dll' (0x6D0D) is already occupied The error is extremely rarely - perhaps just once a day Antivirus software is deinstalled, Windows defender is deactivated. Rebaseall and peflagsall were running. We have this error really not reproduceable on some compile machines. These machines are running a perl script which polls a remote database for running make jobs in parallel (-j flag) - that's all. Normally all works fine - but sometimes we got these fork errors. Is there an possibility to get more information who is occupying the address space? Perhaps I can instrument the cygwin1.dll to wait or do something special - so I can use other tools i.e. sysinternals vmmap, process explorer ... to have a look who is using this address space. Perhaps a self build debug snapshot version with instrumented debug flags will give me some hints? Please - can anyone give me some hints. Any help is welcome. best regards Heiko -- 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
Re: find in root (/) results in stack trace
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 didn't have any problem... > > ...except that find ran into an infinite loop in /proc/registry. It > turned out that this is a result of registry virtualization under UAC. > I fixed that by treating the affected registry keys(*) as symlink, > rather than as directory. > Hello, thanks a lot. $ uname -a CYGWIN_NT-6.1-WOW64 PCFX061 1.7.10s(0.259/5/3) 20120202 16:59:00 i686 Cygwin I can agree - find is running fine. regards Heiko -- 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
rebaseall/peflagsall/perlrebase - which is the recommended way using CPAN modules
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 and peflagsall are run - cause of other fork failures nad runing WIN7/64. But there are still some fork errors (not reproducabale) - perhaps of not using perlrebase. In posting http://thread.gmane.org/gmane.os.cygwin/130879/focus=130884 I've found an information that all perl modules have to be rebased together with perlrebase on top of rebaseall. So I take a deeper look into the perl rebase script and read some postings regarding having problems with fork error. perlrebase will rebase all releated perl5 DLLs together to a address range. This address range should be below the address range used by rebaseall and there has to be free memory space below the perlrebase address range. This is cause of cygwin perl internals (http://thread.gmane.org/gmane.os.cygwin/130879/focus=130884) whil eusing CPAN XS modules. So far so good. Another thing which is done by perlrebase is the following: all DLLs are set to be not to have a dynamicbase (--dynamicbase=0) flag set! On the other hand peflagsall will set the opposite: --dynamicbase=1 for all dlls including perl5 dll. So for me it's really not clear - what to do exactly - to possible resolve fork errors. Another interesting thing is that the default address of perlrebase will conflict with my address range of rebase all. The rebaseall address range will use addresses from 0x7000 .. 0x479c! And the default address range of perlrebase is 0x5700 (I know I can override it) - so both ranges will overlap ... Overriding the address range will break the rebase database which is used since rebase 4.x. So I cannot easily figure out address ranges which will overlap with "rebase - s -i". Can anyone give me a hint - what is correct way in rebaseall/peflags/perreabe cygwin DLLs, perl5 DLLS and perl5 CPAN DLLs. I know that a new perlrebase is under developement - but it's not released yet cause of other problems. The new perlrebase addresses will address more problems (adding more and more CPAN modules, ). But my system is really static - no more CPAN modules will be added - so adding other modules is not the problem. Perhaps this si already solved with the new perlrebase script? So - what is the recommended memory layout (DLLS) on such a system. Any help is welcome. best regards heiko -- 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
Re: find in root (/) results in stack trace
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. regards Heiko -- 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
find in root (/) results in stack trace
Hello, I'm using the latest snapshot. $ uname -a CYGWIN_NT-6.1-WOW64 PCFX061 1.7.10s(0.259/5/3) 20120201 05:28:17 i686 Cygwin Rebaseall and peflagsall are done. Executing "find ." in the root will force a stack trace. *** snip snip snip ente59@PCFX061 / $ find . >/tmp/find.log 0 [main] find 8996 C:\Programme\cygwinTest\bin\find.exe: *** fatal error - cwcsdup would have returned NULL Stack trace: Frame Function Args 0028B4D8 6102F96B (0028B4D8, , , 20039A30) 0028B7C8 6102F96B (6119BD20, 8000, , 6119DB0F) 0028C7F8 61005F0C (611CC458, 0028C824, 6228FE64, ) 0028C818 61005F48 (611CC458, , , 6228FE64) End of stack trace Hangup *** snip snip snip I noticed the problem yesterday with snapshot 2012-01-11. I reproduced it 2012-01-23 and latest snapshot from today 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 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
Re: "Bad address" error with redirection (stdout and stderr) in background process
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 day? regards Heiko -- 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
Re: "Bad address" error with redirection (stdout and stderr) in background process
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 you to expect > a newer snapshot than that. > In my first posting concerning this problem I posted tne used snapshot too (20110111) >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. So I already used teh snapshot of January 11th. best regards Heiko -- 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
Re: "Bad address" error with redirection (stdout and stderr) in background process
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: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: "Bad address" error with redirection (stdout and stderr) in background process
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 Heiko -- 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
"Bad address" error with redirection (stdout and stderr) in background process
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 semicolon (;) using cygwin and non-cygwin(cross compiler) commands. # just an example test.o: test.c echo compile ; cross-gcc -c test.c -o test.o Having multiple targets like this and using for example $ make -j8 |& tee make.log you will get a "bad address" error. /bin/sh: cross-gcc.exe: Bad address makefile:10: recipe for target `test.o' failed I stripped down the problem to the following testcase: $ cat ./testcase.sh #!/bin/sh (( echo 123 ; cmd /c echo 456 ) |& tee tee.log ) & executing the testcase will produce thr following output: $ ./testcase.sh $ 123 ./testcase.sh: line 2: /cygdrive/c/Windows/system32/cmd: Bad address If only redirecting stdout to tee all works fine. The problem occurs ony while mixing cygwin and non cygwin programs. Using snapshot 20110829 all works fine. Any ideas? best regards heiko -- 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
Re: "Bad address" error while building cygwin with make -j2
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.com/ml/#unsubscribe-simple
Re: "Bad address" error while building cygwin with make -j2
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' > Makefile:26: recipe for target `first' failed > make: *** [first] Error 2 > I can confirm it also! I've same different issue: $ uname -a CYGWIN_NT-6.1-WOW64 PCFX061 1.7.10s(0.255/5/3) 20111218 06:46:00 i686 Cygwin $ make -j2 gcc -L/src/cygwin-snapshot-20111213-1/i686-pc-cygwin/winsup -L/src/cygwin- snapshot-20111213-1/i686-pc-cygwin/winsup/cygwin -L/src/cygwin-snapshot- 20111213-1/i686-pc-cygwin/winsup/w32api/lib -isystem /src/cygwin-snapshot- 20111213-1/winsup/include -isystem /src/cygwin-snapshot-20111213- 1/winsup/cygwin/include -isystem /src/cygwin-snapshot-20111213- 1/winsup/w32api/include -B/src/cygwin-snapshot-20111213-1/i686-pc- cygwin/newlib/ -isystem /src/cygwin-snapshot-20111213-1/i686-pc- cygwin/newlib/targ-include -isystem /src/cygwin-snapshot-20111213- 1/newlib/libc/include-I/src/cygwin-snapshot-20111213- 1/winsup/cygwin/include -DPACKAGE_NAME=\"newlib\" - DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.19.0\" - DPACKAGE_STRING=\"newlib\ 1.19.0\" -DPACKAGE_BUGREPORT=\"\" - DPACKAGE_URL=\"\" -I. -I../../../.././newlib/libc/argz -DHAVE_OPENDIR - DHAVE_RENAME -DSIGNAL_PROVIDED -D_COMPILING_NEWLIB -DHAVE_BLKSIZE - DHAVE_FCNTL -DMALLOC_PROVIDED -fno-builtin -g -O2 -c -o lib_a-dummy.o `test -f 'dummy.c' || echo '../../../.././newlib/libc/argz/'`dummy.c gcc -L/src/cygwin-snapshot-20111213-1/i686-pc-cygwin/winsup -L/src/cygwin- snapshot-20111213-1/i686-pc-cygwin/winsup/cygwin -L/src/cygwin-snapshot- 20111213-1/i686-pc-cygwin/winsup/w32api/lib -isystem /src/cygwin-snapshot- 20111213-1/winsup/include -isystem /src/cygwin-snapshot-20111213- 1/winsup/cygwin/include -isystem /src/cygwin-snapshot-20111213- 1/winsup/w32api/include -B/src/cygwin-snapshot-20111213-1/i686-pc- cygwin/newlib/ -isystem /src/cygwin-snapshot-20111213-1/i686-pc- cygwin/newlib/targ-include -isystem /src/cygwin-snapshot-20111213- 1/newlib/libc/include-I/src/cygwin-snapshot-20111213- 1/winsup/cygwin/include -DPACKAGE_NAME=\"newlib\" - DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.19.0\" - DPACKAGE_STRING=\"newlib\ 1.19.0\" -DPACKAGE_BUGREPORT=\"\" - DPACKAGE_URL=\"\" -I. -I../../../.././newlib/libc/argz -DHAVE_OPENDIR - DHAVE_RENAME -DSIGNAL_PROVIDED -D_COMPILING_NEWLIB -DHAVE_BLKSIZE - DHAVE_FCNTL -DMALLOC_PROVIDED -fno-builtin -g -O2 -c -o lib_a-argz_add.o `test -f 'argz_add.c' || echo '../../../.././newlib/libc/argz/'`argz_add.c make: *** read jobs pipe: Resource temporarily unavailable. Stop. make: *** Waiting for unfinished jobs regards Heiko -- 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
Re: "Bad address" error while building cygwin with make -j2
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! *** snip snp snip ** $ uname -a CYGWIN_NT-6.1-WOW64 PCFX061 1.7.10s(0.255/5/3) 20111214 15:56:36 i686 Cygwin $ make -j2 gcc -L/src/cygwin-snapshot-20111213-1/i686-pc-cygwin/winsup -L/src/cygwin- snapshot-20111213-1/i686-pc-cygwin/winsup/cygwin -L/src/cygwin-snapshot- 20111213-1/i686-pc-cygwin/winsup/w32api/lib -isystem /src/cygwin-snapshot- 20111213-1/winsup/include -isystem /src/cygwin-snapshot-20111213- 1/winsup/cygwin/include -isystem /src/cygwin-snapshot-20111213- 1/winsup/w32api/include -B/src/cygwin-snapshot-20111213-1/i686-pc- cygwin/newlib/ -isystem /src/cygwin-snapshot-20111213-1/i686-pc- cygwin/newlib/targ-include -isystem /src/cygwin-snapshot-20111213- 1/newlib/libc/include-I/src/cygwin-snapshot-20111213- 1/winsup/cygwin/include -DPACKAGE_NAME=\"newlib\" - DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.19.0\" - DPACKAGE_STRING=\"newlib\ 1.19.0\" -DPACKAGE_BUGREPORT=\"\" - DPACKAGE_URL=\"\" -I. -I../../../.././newlib/libc/argz -DHAVE_OPENDIR - DHAVE_RENAME -DSIGNAL_PROVIDED -D_COMPILING_NEWLIB -DHAVE_BLKSIZE - DHAVE_FCNTL -DMALLOC_PROVIDED -fno-builtin -g -O2 -c -o lib_a-dummy.o `test -f 'dummy.c' || echo '../../../.././newlib/libc/argz/'`dummy.c gcc -L/src/cygwin-snapshot-20111213-1/i686-pc-cygwin/winsup -L/src/cygwin- snapshot-20111213-1/i686-pc-cygwin/winsup/cygwin -L/src/cygwin-snapshot- 20111213-1/i686-pc-cygwin/winsup/w32api/lib -isystem /src/cygwin-snapshot- 20111213-1/winsup/include -isystem /src/cygwin-snapshot-20111213- 1/winsup/cygwin/include -isystem /src/cygwin-snapshot-20111213- 1/winsup/w32api/include -B/src/cygwin-snapshot-20111213-1/i686-pc- cygwin/newlib/ -isystem /src/cygwin-snapshot-20111213-1/i686-pc- cygwin/newlib/targ-include -isystem /src/cygwin-snapshot-20111213- 1/newlib/libc/include-I/src/cygwin-snapshot-20111213- 1/winsup/cygwin/include -DPACKAGE_NAME=\"newlib\" - DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.19.0\" - DPACKAGE_STRING=\"newlib\ 1.19.0\" -DPACKAGE_BUGREPORT=\"\" - DPACKAGE_URL=\"\" -I. -I../../../.././newlib/libc/argz -DHAVE_OPENDIR - DHAVE_RENAME -DSIGNAL_PROVIDED -D_COMPILING_NEWLIB -DHAVE_BLKSIZE - DHAVE_FCNTL -DMALLOC_PROVIDED -fno-builtin -g -O2 -c -o lib_a-argz_add.o `test -f 'argz_add.c' || echo '../../../.././newlib/libc/argz/'`argz_add.c make: *** read jobs pipe: Bad address. Stop. make: *** Waiting for unfinished jobs make: INTERNAL: Exiting with 1 jobserver tokens available; should be 2! *** snip snp snip ** regards Heiko -- 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
Re: "Bad address" error while building cygwin with make -j2
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 -- 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
"Bad address" error while building cygwin with make -j2
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. I installed snapshot cygwin-inst-20111213.tar.bz2. I run rebaseall and peflagsall and did a reboot. $ uname -a CYGWIN_NT-6.1-WOW64 PCFX061 1.7.10s(0.255/5/3) 20111213 04:12:34 i686 Cygwin Here is my configuration $ cygcheck -c >cygcheck.log ftp://temp3-ro:tem...@ftp.arburg.com/temp3/make_strace.log Her you will find an strace of the problem: $ strace -o make_strace.log make -j2 ftp://temp3-ro:tem...@ftp.arburg.com/temp3/cygcheck.log I've downloaded cygwin-src-20111213.tar.bz2. running make -j2 in /cygwin-snapshot-20111213-1/i686-pc-cygwin/newlib/libc/argz will produce the following error: *** snip snip snip *** ente59@PCFX061 /src/cygwin-snapshot-20111213-1/i686-pc-cygwin/newlib/libc/argz $ rm *.o ente59@PCFX061 /src/cygwin-snapshot-20111213-1/i686-pc-cygwin/newlib/libc/argz $ make -j2 gcc -L/src/cygwin-snapshot-20111213-1/i686-pc-cygwin/winsup -L/src/cygwin- snapshot-20111213-1/i686-pc-cygwin/winsup/cygwin -L/src/cygwin-snapshot- 20111213-1/i686-pc-cygwin/winsup/w32api/lib -isystem /src/cygwin-snapshot- 20111213-1/winsup/include -isystem /src/cygwin-snapshot-20111213- 1/winsup/cygwin/include -isystem /src/cygwin-snapshot-20111213- 1/winsup/w32api/include -B/src/cygwin-snapshot-20111213-1/i686-pc- cygwin/newlib/ -isystem /src/cygwin-snapshot-20111213-1/i686-pc- cygwin/newlib/targ-include -isystem /src/cygwin-snapshot-20111213- 1/newlib/libc/include-I/src/cygwin-snapshot-20111213- 1/winsup/cygwin/include -DPACKAGE_NAME=\"newlib\" - DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.19.0\" - DPACKAGE_STRING=\"newlib\ 1.19.0\" -DPACKAGE_BUGREPORT=\"\" - DPACKAGE_URL=\"\" -I. -I../../../.././newlib/libc/argz -DHAVE_OPENDIR - DHAVE_RENAME -DSIGNAL_PROVIDED -D_COMPILING_NEWLIB -DHAVE_BLKSIZE - DHAVE_FCNTL -DMALLOC_PROVIDED -fno-builtin -g -O2 -c -o lib_a-dummy.o `test -f 'dummy.c' || echo '../../../.././newlib/libc/argz/'`dummy.c gcc -L/src/cygwin-snapshot-20111213-1/i686-pc-cygwin/winsup -L/src/cygwin- snapshot-20111213-1/i686-pc-cygwin/winsup/cygwin -L/src/cygwin-snapshot- 20111213-1/i686-pc-cygwin/winsup/w32api/lib -isystem /src/cygwin-snapshot- 20111213-1/winsup/include -isystem /src/cygwin-snapshot-20111213- 1/winsup/cygwin/include -isystem /src/cygwin-snapshot-20111213- 1/winsup/w32api/include -B/src/cygwin-snapshot-20111213-1/i686-pc- cygwin/newlib/ -isystem /src/cygwin-snapshot-20111213-1/i686-pc- cygwin/newlib/targ-include -isystem /src/cygwin-snapshot-20111213- 1/newlib/libc/include-I/src/cygwin-snapshot-20111213- 1/winsup/cygwin/include -DPACKAGE_NAME=\"newlib\" - DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.19.0\" - DPACKAGE_STRING=\"newlib\ 1.19.0\" -DPACKAGE_BUGREPORT=\"\" - DPACKAGE_URL=\"\" -I. -I../../../.././newlib/libc/argz -DHAVE_OPENDIR - DHAVE_RENAME -DSIGNAL_PROVIDED -D_COMPILING_NEWLIB -DHAVE_BLKSIZE - DHAVE_FCNTL -DMALLOC_PROVIDED -fno-builtin -g -O2 -c -o lib_a-argz_add.o `test -f 'argz_add.c' || echo '../../../.././newlib/libc/argz/'`argz_add.c make: *** read jobs pipe: Bad address. Stop. make: *** Waiting for unfinished jobs make: INTERNAL: Exiting with 1 jobserver tokens available; should be 2! *** snip snip snip *** Running without -j flag all works fine. I did the following steps: running configure and run make without -j flag for the first build: $ tar xjf /cygdrive/c/Programme/cygwin/mirror/snapshots/cygwin-src- 20111213.tar.bz2 $ cd cygwin-snapshot-20111213-1 $ md myinstall $ ./configure --prefix=/src/cygwin-snapshot-20111213-1/myinstall $ make Then I tried make using -j flag in a sub directory. $ cd i686-pc-cygwin/newlib/libc/argz $ rm *.o $ make -j2 I hope other users can reproduce same problem. regards Heiko -- 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
Re: Another call for filesystem testing
Here's a test from Win7/64 SP1 with MVFS version 7.1.1.7 (Wed Aug 3 22:33:34 2011). ente59@PCFX061 /cygdrive/c/MyDevelopment/cygwin/test-qfif $ uname -a CYGWIN_NT-6.1-WOW64 PCFX061 1.7.10s(0.255/5/3) 2029 17:41:48 i686 Cygwin ente59@PCFX061 /cygdrive/c/MyDevelopment/cygwin/test-qfif $ /usr/lib/csih/getVolInfo /cygdrive/v Device Type: 7 Characteristics: 10 Volume Name: Serial Number : 36984713 Max Filenamelength : 255 Filesystemname : Flags : 3 FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: FALSE FILE_PERSISTENT_ACLS: FALSE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : FALSE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE ente59@PCFX061 /cygdrive/c/MyDevelopment/cygwin/test-qfif $ ./test- qfif.exe /cygdrive/v/Stg_V5.108_ente59_iv/stg2/steuerung /cygdrive/v/Stg_V5.108 _ente59_iv/stg2/steuerung/makefile NtQueryFullAttributesFile(\??\V:\Stg_V5.108_ente59_iv\stg2\steuerung) by name works NtQueryFullAttributesFile(\??\V:\Stg_V5.108_ente59_iv\stg2\steuerung) by handle works NtQueryFullAttributesFile(\??\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/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
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 scripts, cygcheck or compilers. I see the error while running mingw compiler too! c:/programme/cygwin/bin/sh: /cygdrive/c/programme/cygwin/bin/cygcheck: Bad address c:/programme/cygwin/bin/sh: C:/clearcase/xview/pid/pid_V3.7_2011.05.06_019/gnu/4.1.2-vxworks-6.7/x86- win32/bin/ccpentium.exe: Bad address c:/programme/cygwin/bin/sh: ../../tools/buildtools/arb/liters/liters.2_5/liters : Bad address But all errors are not reproduceable at the moment - so I cannot send a testcase. With snapshot 20110829 I only got some "forking errors" - but never "Bad address" erros. Can anyone explain me a little bit in detail the "Bad address". So perhaps I can find a testcase. In older postings I found "Bad errors" - but I think these are all related to older cygwin version 1.7.7 and older. regrads Heiko -- 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
unattended setup: how update categories including new packages
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 were downloaded seperately before. .\setup.exe -q -L -l C:\Programme\cygwin\mirror\ -R C:\Programme\cygwin -n -d -CAdmin,Archive,Base,Database,Devel,Doc,Editors,Graphics,Interpreters, Libs,Mail,Math,Mingw,Net,Perl,Publishing,Python,Science,Shells, System,Text,Utils,Web,X11 All works fine. Today I tried to update my installation with unattended setup. First I download all new packages to my harddisk without installation. Then I tried to call setup in unattended mode - I know that setup knows all my installed packages so I use the following setup call - same call as above but without flag -C for categories. .\setup.exe -q -L -l C:\Programme\cygwin\mirror\ -R C:\Programme\cygwin -n -d All works fine - but newer packages are missing - cause they were not installed in my old installation - i.e nosleep, pscan, outguess, ... Is there a possibility to update a cygwin installation on base of categories? I tried -C flag with the whole list as above, but no package is installed. Is there another possibility to update a cygwin installation with unattended setup? Are newer package dependencies to not installed packages resolved by setup? best regards Heiko -- 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
Re: help for diagnose unpedictable "fork errors", "cygheap base msimatch errors"
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 using 2011-11-08 snapshot on win7/64 and it is working > fine (2011-11-14 has a problem and I have not yet tested 2011-11-16) > > Regards > Marco > > I'm sorry - but I'm not sure what you mean exactly. Perhaps my english is too bad - I'm sorry for this. Or I'm writing to many lines ... We've some unpredictabel errors and I'm looking for a solution to gather more information about the erros to send them perhaps into this group - so other people can perhaps help. Regards Heiko -- 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
help for diagnose unpedictable "fork errors", "cygheap base msimatch errors"
Hello, we've still cygwin system errors. I use snapshot 20111030 and all other colleagues snapshot 20110829. We've done rebaseall and peflagsall. We have win7/64 (CYGWIN_NT-6.1-WOW64). All errors are unpredictable - so there is really no possible testcase. I noticed the following problems: 1. runing perl: child_info_fork::abort: address space needed by 'IO.dll' (009D) is already occupied 2. running perl 0 [main] perl 22992 C:\programme\cygwin\bin\perl.exe: *** fatal error - cy gheap base mismatch detected - 0x612527E0/0xF927E0. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start->Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. --> there is definitely no other currrent cygwin1.dll 3. running sh.exe from within make 0 [main] sh 5564 child_info_fork::abort data segment start: parent(0x682000) ! = child(0x32000) m.sh fork: retry: Resource temorarily unavailable 4. running make 0 [main] make-3.80 22116 child_info::sync: wait failed, pid 21196, Win32 error 1892 How can I gather more informations about the problems with other cygwin tools. I'm definitely no cygwin professional. I already tried strace - I have an strace log of problem 1.) - if this would be helpful, I can post it. OK - I already checked the BLODA - and yes one is running on our system - Symantec Endpoint Protection Version 12.x. We deinstalled it on 3 PCs - perhaps we will see no more error there. But cause of unpedictable errors and no testcase it's not a solution to deinstall it on all machines. Is there a testcase for detecting Symantec as the real problem - we are in contact with Symantec too. Does anyone know the problem of using Symantec Endpoint Protection a little bit in details. Is it possible that the unloading of DLL code is delayed? 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 -- 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
how to log "fork errors", cygheap errors with syslogd
Hello, I'm sorry - but cause of sometimes having unpredictable and unreproduceable cygwin errors like "fork error, cygheap check", I trieded to run syslogd to log these all these errors in /var/log/messages. But these kind of errors are not logged there. How do I have to configure 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 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
many "fork failed" errors after doing rebaseall amd peflagsall
Hello all, we've many problems i.e. using make, perl. We often will get errors like the following: 1) abnormal program termination C:\TEMP\make7078823.sh: fork failed: no child processes [1] 2)0 [main] sh 71664 child_info_fork::abort: address space needed by 'cyggccs- 1.dll' (6913) is already occupied c:/programme/cygwin/bin/sh: fork: Resource temporarily unavailable 3) child_info_fork::abort: address space needed by 'DBI.dll' (00CF) is already occupied We use cygwin 1.7.9 with snapshot "cygwin-inst-20110829.tar.bz2". I did a complete rebaseall 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 some more hints. 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
Re: fork: Resource temporarily unavailable: address space is already occupied
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. > > > >The error is intermittent. > >Sometimes I have this error and sometimes not - really not reproduceable. > >If it occurs - it's always while compiling another sourcefile. > > > >What is compiled: C-Files. > >We use VxWorks GNU-MinGW Crosscompiler by (Wind River Systems). > >The make is an old cygwin (1.5.x) make-3.80 and the sh is a cygwin (1.5.x) by > >Wind River Systems. > > This is certainly an unsupported configuration. Contact Wind River if you > want support. What is unsupported - using old cygwin 1.5.x binaries ? OK - using 1.5.x binaries is not supported - but it should work? Or not? If you mean WindRiver MinGW Gnu Compiler - not supported (yes, of course) - but it' only a win32 (non cygwin program) and I was asked what's running ... heiko -- 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
Re: is using old make.exe (3.80) (cygwin 1.5.x) within cygwin 1.7.x OK
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 Domänen-Benutzer 816396 Jul 21 09:24 make-3.80.exe -rwxr-xr-x 1 ente59 Domänen-Benutzer 151552 Jan 19 2011 make-3.81.exe -rwxr-xr-x 1 ente59 Domänen-Benutzer 1564971 Dec 23 2009 make-3.81.rwalker.exe -rwxr-xr-x 1 ente59 Domänen-Benutzer 1582104 Aug 1 2010 make-3.82.rwalker.exe $ strip make*rwalker* $ ls -l make-* -rwxr-xr-x 1 ente59 Domänen-Benutzer 816396 Jul 21 09:24 make-3.80.exe -rwxr-xr-x 1 ente59 Domänen-Benutzer 151552 Jan 19 2011 make-3.81.exe -rwxr-xr-x 1 ente59 Domänen-Benutzer 1170958 Aug 11 07:18 make-3.81.rwalker.exe -rwxr-xr-x 1 ente59 Domänen-Benutzer 1173518 Aug 11 07:18 make-3.82.rwalker.exe regards Heiko -- 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
Re: fork: Resource temporarily unavailable: address space is already occupied
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 occurs - it's always while compiling another sourcefile. What is compiled: C-Files. We use VxWorks GNU-MinGW Crosscompiler by (Wind River Systems). The make is an old cygwin (1.5.x) make-3.80 and the sh is a cygwin (1.5.x) by Wind River Systems. regrads Heiko -- 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
Re: fork: Resource temporarily unavailable: address space is already occupied
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 perl are a few examples. No other application is running with the exception of perl (for scanning/starting new jobs). The system is used as a compile machine. regras Heiko -- 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
Re: fork: Resource temporarily unavailable: address space is already occupied
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 of fork failure. > > > > I can see I'm going to regret exposing these errors. They have been there > > for a couple of months but they were strace only. I just made them more > > visible. > > > > This. Is a recording. > > > > rebaseall and peflagsall should fix the problem. > > > > After rebaseall and peflagsall, I will get the following errors while running > "make -j " > > *** snip snip snip * > abnormal program termination > C:\TEMP\make556888.sh: fork failed: no child processes [1] > *** snip snip snip * > I forgot, is it possible a error of make? I use old make 3.80 (binary from cygwin 1.5.x) .. .. and I do not run rebase/peflags against it. Is it allowed to run old make (see http://thread.gmane.org/gmane.os.cygwin /128011) best regards Heiko -- 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
Re: fork: Resource temporarily unavailable: address space is already occupied
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 going to regret exposing these errors. They have been there > for a couple of months but they were strace only. I just made them more > visible. > > This. Is a recording. > > rebaseall and peflagsall should fix the problem. > After rebaseall and peflagsall, I will get the following errors while running "make -j " *** snip snip snip * abnormal program termination C:\TEMP\make556888.sh: fork failed: no child processes [1] *** snip snip snip * Any other hints? best regards Heiko -- 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
is using old make.exe (3.80) (cygwin 1.5.x) within cygwin 1.7.x OK
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 future problems or side effects. best regrads Heiko -- 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
fork: Resource temporarily unavailable: address space is already occupied
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 child_info_fork::abort: address space needed by 'cyggcc_s-1.dll' (67F0) is already occupied c:/programme/cygwin/bin/sh: fork: Resource temporarily unavailable The question is: Is there somethink I can to to avoid this error? Why is this address already occupied? There are losts of postings about rebaseall, peflagsall ... My system Win7/64, Intel Xeon CPU, 12MB RAM. uname -a --> "CYGWIN_NT-6.1-WOW64 PC01028 1.7.10s(0.249/5/3) 20110803 18:07:45 i686 Cygwin" Please can anyone give me a hint. best regards Heiko -- 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
Re: Slow performance Win7/64
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 information for me. So the current slow implementation is a workaround for another race condition. So - is there no other way for fixing that race contion! Is there another implememtaion for fixing the slow signaling without getting a new race condition. Heiko -- 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
Re: Slow performance Win7/64
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. XP/32 Win7/64 cygwin snapshot 2011-07-21 34 12 cygwin snapshot 2011-07-21 SIGPATCH 44 37 As you see XP and Win7 now a really faster. Win7 3x speed - wow. > but i can't make sure it doesn't include side-effects. please test it on > your pc. let's hope it would work. I will test ist. I've already recognize one positive side effect: The CTRL-C Handler works now even faster. With unpatched cygwin1.dll there was a realy long delay, after pressing CTRL-C. Can you agree this too? I'm very interested if this patch will be released or not. I'm interested in the opionion opinion of C. Vinschen and C Faylor. best regards heiko -- 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
Slow performance Win7/64
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 from
within bash/make.
I found severeal postings regarding this problem and I can reproduce the problem
with a small testcase which I found in another posting.
DATE=`which date` ; { while true ; do $DATE ; done } > list.log
I count the lines in list.log with same timestamp I will get the following
timestamps per seconds:
XP/32 Win7/64
cygwin 34 12
mingw 35 34
MKS (eval version) 107 99
I've searched other postings for a solution - but I cannot find one.
Using Cygwin since several years I'm very sad cause Cygwin seem to be a really
good and full implmentation of UNIX commands.
So the question is:
Is it a known problem?
Is it really OS (Win7) specific?
Why is this problem not solved - cause it is to difficult to find? Yes I know
it's open source and I'm a programmer too - but I'm realy not a programmer
having the knowledge of Cygwin internal details.
Is there a workaround for that problem?
Any hints are welcome.
best regards
Heiko
--
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
Re: [bash or DLL] Memory leak in childs
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 227MB to 334MB and the > system went haywire in the same fashion as before. I rebooted again. I start the batches with the following command (without /b): start test2.bat about 10 times. And after 7 minutes all batches are stopped with the following error: "Für diesen Befehl ist nicht genügend Speicher verfügbar." (german WIN7) ==> "not enough memory for that command" But the memory is freed again and win7/64 SP1 works fine. (just for information - cause your system went haywire). OK it really seems to be win7 problem. I'm really glad to hear that this is not a cygwin error. But thanks a lot for figuring that out. heiko -- 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
Re: [bash or DLL] Memory leak in childs
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: Cannot allocate memory
> > *** snip snip snip
>
> Are you saying you continue to see virtual memory use increasing over time and
> eventually the above output is seen? It's hard to tell because what's quoted
> above doesn't match your earlier report. Is test2.sh the script you used for
> the second example in your first post on this subject?
Again I'm sorry - I just used another small testcase doing the same.
See start/test description at the end of the message.
** snip snip snip **
$ cat test2.sh
#!/bin/sh
trap "echo TRAP; exit -1" SIGHUP SIGINT SIGQUIT SIGILL SIGTRAP SIGABRT SIGEMT SI
GFPE SIGKILL SIGBUS SIGSEGV SIGSYS SIGPIPE SIGALRM SIGTERM SIGURG SIGSTOP SIGTST
P SIGCONT SIGCHLD SIGTTIN SIGTTOU SIGIO SIGXCPU SIGXFSZ SIGVTALRM SIGPROF SIGWIN
CH SIGPWR SIGUSR1 SIGUSR2 SIGRTMAX
while ./exiter-vs2003.exe ; do
echo -n $?
done
echo RC=$?
** snip snip snip **
exiter-vs2003.c.c ist compiled with MS Visual Studio 2003
** snip snip snip **
$ cat exiter-vs2003.c
#include
int main(int argc, char** argv[])
{
printf(".");
return 0;
}
** snip snip snip **
> However, I understand that Windows 7 has an anti-spyware service named Windows
> Defender included and enabled by default. Is it enabled on your system? If
> it
Thanks a lot - indeed MS defender was active - I deactivate it!
Here is my description of the testcase.
Step 1) Open one bash console for calling "/usr/bin/free" from time to time
to see the "lost memory" while running step 2.
$ free
total used free sharedbuffers cached
Mem: 125402321862512 10677720 0 0 0
-/+ buffers/cache:1862512 10677720
Swap: 12540232 0 12540232
Wait 10 seconds ...
total used free sharedbuffers cached
Mem: 125402321862512 10677720 0 0 0
-/+ buffers/cache:1862512 10677720
Swap: 12540232 0 12540232
Again wait 10 seconds ...
$ free
total used free sharedbuffers cached
Mem: 125402321863620 10676612 0 0 0
-/+ buffers/cache:1863620 10676612
Swap: 12540232 0 12540232
Again wait 10 seconds ...
$ free
total used free sharedbuffers cached
Mem: 125402321873316 10666916 0 0 0
-/+ buffers/cache:1873316 10666916
Swap: 12540232 0 12540232
Again wait 10 seconds ...
$ free
total used free sharedbuffers cached
Mem: 125402321875340 10664892 0 0 0
-/+ buffers/cache:1875340 10664892
Swap: 12540232 0 12540232
Step 2) Open another or more bash console for calling "test2.sh"
$ ./test2.sh
you will see lots of lines like this
snip snip snip ***
.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0
.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0
.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0
snip snip snip ***
If running more "test2.sh" in parallel (I use up to 10) the memory consumption
is even more.
As you see - on my system memory is lost ...
I just see that between two free calls or in Windows Task Manager - of course
other programm need memory too - but the memory always shrinks.
best regards
Heiko
--
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
Re: [bash or DLL] Memory leak in childs
Hello, I just can confirm the same problem with latest cygwin1.dll (cygwin1-20110713.dll.bz2) on Windows 7/64 (fast XEON CPU). I've seen this problem while testing other "exiter" - problem with the following script. *** snip snip snip ** #!/bin/sh set -e while true; do ./exiter.exe echo -n $? done *** snip snip snip ** Please regard: exiter is a native WIN32 executable. The virtual memory (windows task manager) grows and grows over the time. The cygwin eats all memory til no more available. But after alle cygwin processes are closed the memory is freed. I did another native cygwin test using true.exe: *** snip snip snip ** #!/bin/sh echo "starting $0" while /usr/bin/true do : done echo "exiting $0" *** snip snip snip ** Using this script the used virtual memory (windows task manager) grows too, but even more slowly - so 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
fcntl() bug? if called second times!
Hello,
I try to comiple an run the distcc package - but I get errors while running.
I figured out, tha the problems are the fcntl() calls - perhaps
ther is a bug in cygwin?
The following code runs differently in cygwin and linux.
If I want ro lock the whole file twice, but still the same process, I will
get an "permission denied" error on cygwin.
The same code works on linux!
===> Cygwin console
heiko@HEIKO ~/src/fslock
$ ./fslocktest
Lock 1
Lock 2
lock failed: fslocktest.txt: Permission denied
===> linux console
heiko@linux:~/src/fslock> ./fslocktest
Lock 1
Lock 2
Below is the code to reproduce the error.
I'm using the following software:
- Windows XP Professional Ver 5.1 Build 2600 Service Pack 1
CYGWIN=ntsec
- Cygwin DLL version info:
DLL version: 1.3.18
DLL epoch: 19
DLL bad signal mask: 19005
DLL old termios: 5
DLL malloc env: 28
API major: 0
API minor: 69
Shared data: 3
DLL identifier: cygwin1
Mount registry: 2
Cygnus registry name: Cygnus Solutions
Cygwin registry name: Cygwin
Program options name: Program Options
Cygwin mount registry name: 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
snip - snip - snip
/*
make CFLAGS="-Wall -g -O0" testfcntl.c
*/
int main(int argc, char** argv, char** envp)
{
int fd ;
char* fname = "fslocktest.txt";
int rc;
struct flock lockparam;
lockparam.l_type = F_WRLCK;
lockparam.l_whence = SEEK_SET;
lockparam.l_start = 0;
lockparam.l_len = 0;/* whole file */
fd = open(fname, O_WRONLY|O_CREAT, 0600);
if (fd == -1 && errno != EEXIST)
{
printf("failed to creat %s: %s", fname, strerror(errno));
return errno;
}
printf("Lock 1\n");
rc = fcntl(fd, F_SETLK, &lockparam);
if (rc==-1)
{
printf("lock failed: %s: %s", fname, strerror(errno));
return errno;
}
printf("Lock 2\n");
rc = fcntl(fd, F_SETLK, &lockparam);
if (rc==-1)
{
printf("lock failed: %s: %s", fname, strerror(errno));
return errno;
}
close(fd);
return 0;
}
snip - snip - snip
Heiko Elger
,,,
(o o)
+oOO--(_)--OOo+
| |
| Email:[EMAIL PROTECTED] |
| |
| bitte .spam in der Email-Adresse entfernen|
| please remove .spam |
| |
|.oo0O O0oo.|
|( ) ( )|
+-\ (-) /-+
\_) (_/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
anyone using distcc with cygwin without errors?
Hello, I'm trying distcc v0.15 - but without success. Using distcc like the following generates errors: $ distcc gcc -g -O0 -c -o modul1.o modul1.c distcc[2216] (dcc_scan_args) scanning arguments: gcc -g -O0 -c -o modul1.o modul1.c distcc[2216] (dcc_scan_args) found object/output file "modul1.o" distcc[2216] (dcc_scan_args) found input file "modul1.c" distcc[2216] compile from modul1.c to modul1.o distcc[2216] (dcc_lock_host) locked /tmp/distcc_03eb/lock_localhost_000 distcc[2216] (dcc_lock_one) compile on localhost distcc[2216] (dcc_lock_host) ERROR: lock /tmp/distcc_03eb/lock_localhost_000 failed: Permission denied distcc[2216] (dcc_lock_host) locked /tmp/distcc_03eb/lock_localhost_001 distcc[2216] (dcc_lock_one) compiler on localhost distcc[2216] exec on localhost: gcc -g -O0 -c -o modul1.o modul1.c distcc[2216] (dcc_spawn_child) forking to execute gcc -g -O0 -c -o modul1.o modul1.c distcc[2216] (dcc_spawn_child) child started as pid2300 distcc[2216] (dcc_collect_child) child 2300 terminated with status 0 distcc[2216] (dcc_report_rusage) gcc resource usage: 0.13s user, 0.11s system distcc[2216] compile on DURON800 completed ok distcc[2216] (dcc_exit) exit: code 0; self: 0.02 user 0.02 sys; children: 0.13 user 0.11 sys distcc[2216] (dcc_cleanup_tempfiles) deleted 0 temporary files I using Windows XP Professional (with SP1). Filesystem: NTFS I'm usign the lates cygwin release. Here are some informations: $ uname -a CYGWIN_NT-5.1 DURON800 1.3.17(0.67/3/2) 2002-11-27 18:54 i686 unknown $ echo $CYGWIN ntsec $ id uid=1003(heiko) gid=513(Kein) groups=513(Kein),545(Benutzer),547(Hauptbenutzer $ ls -ld /tmp drwxrwxrwx+ 3 Administ Kein0 Dec 15 19:02 /tmp $ ls -l /tmp 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_localhost_001 Heiko Elger ,,, (o o) +oOO--(_)--OOo+ | | | Email:[EMAIL PROTECTED] | | | | bitte .spam in der Email-Adresse entfernen| | please remove .spam | | | |.oo0O O0oo.| |( ) ( )| +-\ (-) /-+ \_) (_/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
