Re: strange crashes on invocation
On Dec 10, 2010, at 3:36 AM, Corinna Vinschen wrote: Hi Heath, [snip] The latest snapshot from http://cygwin.com/snapshots.html contains another patch which should avoid this problem. Can you please test? Unfortunately, I'm not in a position to be able to repro the problem. Sorry... -heath -- 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: Problem with fork() in latest snapshot
On Dec 7, 2010, at 9:55 AM, Christopher Faylor wrote: I ran the test case in a loop on my Windows XP system under various conditions - no load, load, no load with most services stopped. I couldn't reproduce the problem. I also tried on a virtual system running Windows 7 64-bit and couldn't duplicate it. So, I'm currently stumped. I guess I'll try to add some instrumentation to catch the case where this fails. cgf That's odd, the test case was failing for me on Win7 x64, x32, and x32 under virtualization. FWIW, the test case is apparently working now on the latest snapshot (tried 20101212). But if I run it in strace, there's still an exception message hidden in the output: --- Process 3916, exception C005 at 610E124A As mentioned in another message, I was seeing this exception in even the released 1.7.7-1 cygwin when running in strace (even though the test case was apparently working). It might be moot, as there's no sign of a problem when the test case is run normally. I'll attach the trace output of the testcase running under the latest snapshot. 31 31 [main] testfork 3916 open_shared: name shared.5, n 5, shared 0x60FB (wanted 0x60FB), h 0xC8 57345765 [main] testfork 3916 heap_init: heap base 0x9B, heap top 0x9B 10326797 [main] testfork 3916 open_shared: name S-1-5-21-3346415893-1069646457-3062309592-1002.1, n 1, shared 0x60FC (wanted 0x60FC), h 0xCC 1296926 [main] testfork 3916 user_info::create: opening user shared for 'S-1-5-21-3346415893-1069646457-3062309592-1002' at 0x60FC 1837109 [main] testfork 3916 user_info::create: user shared version 6112AFB3 22379346 [main] testfork 3916 dll_crt0_0: finished dll_crt0_0 initialization 1419 10765 [main] testfork 3916 _cygtls::remove: wait 0x 378 11143 [main] testfork 3916 _cygtls::remove: removed 0x22CE64 element 0 2067 13210 [main] testfork 3916 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\heath\testfork, no-keep-rel, no-add-slash) 313 13523 [main] testfork 3916 normalize_win32_path: C:\cygwin\home\heath\testfork = normalize_win32_path (C:\cygwin\home\heath\testfork) 223 13746 [main] testfork 3916 mount_info::conv_to_posix_path: /home/heath/testfork = conv_to_posix_path (C:\cygwin\home\heath\testfork) 1054 14800 [main] testfork 3916 _cygwin_istext_for_stdio: fd 0: not open 460 15260 [main] testfork 3916 _cygwin_istext_for_stdio: fd 1: not open 108 15368 [main] testfork 3916 _cygwin_istext_for_stdio: fd 2: not open 561 15929 [main] testfork (3916) open_shared: name cygpid.3916, n 3916, shared 0x60FE (wanted 0x60FE), h 0x114 216 16145 [main] testfork 3916 ** 111 16256 [main] testfork 3916 Program name: C:\cygwin\home\heath\testfork\testfork.exe (pid 3916, ppid 1) 108 16364 [main] testfork 3916 App version: 1007.7, api: 0.230 107 16471 [main] testfork 3916 DLL version: 1007.8, api: 0.233 107 16578 [main] testfork 3916 DLL build:20101212 00:50:41SNP 169 16747 [main] testfork 3916 OS version: Windows NT-6.1 106 16853 [main] testfork 3916 Heap size:402653184 107 16960 [main] testfork 3916 ** 106 17066 [main] testfork 3916 pinfo::thisproc: myself-dwProcessId 3916 200 17266 [main] testfork 3916 time: 1292174607 = time (0) 2122 19388 [main] testfork 3916 parse_options: glob (called func) 257 19645 [main] testfork 3916 parse_options: returning 116 19761 [main] testfork 3916 environ_init: GetEnvironmentStrings returned 0x267A88 233 19994 [main] testfork 3916 environ_init: 0x9D8298: !::=::\ 214 20208 [main] testfork 3916 environ_init: 0x9D82A8: ALLUSERSPROFILE=C:\ProgramData 218 20426 [main] testfork 3916 environ_init: 0x9D82D0: APPDATA=C:\Users\heath\AppData\Roaming 214 20640 [main] testfork 3916 environ_init: 0x9D8300: COMMONPROGRAMFILES=C:\Program Files\Common Files 249 20889 [main] testfork 3916 environ_init: 0x9D8338: COMPUTERNAME=HEATH-PC 221 21110 [main] testfork 3916 environ_init: 0x9D8358: COMSPEC=C:\Windows\system32\cmd.exe 218 21328 [main] testfork 3916 environ_init: 0x9D8388: CVS_RSH=/bin/ssh 218 21546 [main] testfork 3916 environ_init: 0x9D83A0: CYGWIN=noglob 216 21762 [main] testfork 3916 environ_init: 0x9D83B8: FP_NO_HOST_CHECK=NO 255 22017 [main] testfork 3916 getwinenv: can't set native for HOME= since no environ yet 261 22278 [main] testfork 3916 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\heath, no-keep-rel, no-add-slash) 113 22391 [main] testfork 3916 normalize_win32_path: C:\cygwin\home\heath = normalize_win32_path (C:\cygwin\home\heath) 113 22504 [main] testfork 3916 mount_info::conv_to_posix_path: /home/heath = conv_to_posix_path (C:\cygwin\home\heath) 311 22815 [main] testfork 3916 win_env::add_cache: posix /home/heath 106
Re: unable to type command into Cygwin after running 'tail'
On Dec 2, 2010, at 1:59 PM, Andy Koppe wrote: On 2 December 2010 18:40, Charles Wilson wrote: On 12/2/2010 1:27 PM, David Rothenberger wrote: Illia Bobyr wrote: On 12/1/2010 8:53 PM, David Rothenberger wrote: Try typing reset or stty sane (without the quotes) and pressing Enter. You won't see what you're typing, but after the shell should work again. Would you, please, elaborate on this a little bit? Maybe a link or a reference that explains why this is happening? I'm sorry, I can't. I don't know why it is happening. I just know how to recover from it as a user. I've noticed that this misbehavior occurs more frequently these days: ctrl-c'ing some tasks (tail, less, maybe a few others) ends up with the terminal settings all scrogged up FWIW, I can't reproduce this, even if I kill the tail or less with SIGKILL, thus giving them no chance to do any cleanup. (I assume you use 'less -K' to allow it to be ctrl-c'ed?) Which shell do people who've seen the problem use? Is it an intermittent issue? If you SIGKILL a 'less' while it has the tty set for raw/noecho then the tty will stay in that mode. Bash apparently resets the tty to normal for you after the process is killed (actually, bash's readline normally runs the tty in a psuedo-raw mode [-icanon min=1 -echo] as a matter of course). If you run 'less' from an 'ash' shell then SIGKILL it, the ash shell will need 'stty sane' typed in. Also, the OP said the problem was happening on pipelines like 'tail | grep'. Neither tail nor grep muck with tty settings (that I know of), so if the tty is ending up with echo disabled, it's got to be the shell leaving it that way. Perhaps there's some kind of race condition in the shell's signal processing? So again, we'll need to know which shell this is happening with and a way to reliably repro the issue to have any hope of fixing it. -heath -- 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: Problem with fork() in latest snapshot
On Nov 16, 2010, at 9:41 AM, Corinna Vinschen wrote: On Nov 10 13:43, Heath Kehoe wrote: I have ruby 1.9.2 which I built from source. It works fine in cygwin 1.7.7 and earlier, but in the current snapshot when it does a fork, the child process dies pretty much instantly. I've put together a test case (see attached) which replicates what ruby is doing so that this problem can be repro'd without needing to build ruby. It seems that the failure only happens when the fork call is in a dll, and it also seems to depend on manipulating threads in close proximity to the fork. Here's the test program under 1.7.7: $ uname -a CYGWIN_NT-6.1-WOW64 hkehoe1 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin $ ./testfork Before fork After fork pid=5060 After fork pid=0 subprocess status 0 (0x0) And here it is in the snapshot: $ uname -a CYGWIN_NT-6.1-WOW64 hkehoe1 1.7.8s(0.233/5/3) 20101102 14:03:08 i686 Cygwin $ ./testfork Before fork After fork pid=3808 subprocess status 32512 (0x7f00) Note the missing 'After fork' message from the child and the -127 exit status. An strace of testfork will reveal this error occurring shortly after the fork returns in the child: --- Process 2944, exception C005 at 610E4B8C (the process ID is the child's) Would you mind to test which snapshot introduced this problem? I apologize for the delay, but I've had an abrupt career change (the entire studio was closed down). I had to resubscribe under a new email address. And I'm using 32-bit Win7 now instead of 64-bit Win7. But I do have some more information: -- Beginning with snapshot 20100901, the test program produces no output. -- Beginning with snapshot 20100926, the test program produces output consistent with the newest snapshots (no output from the child process; child process exits -127) -- If I run the test program in strace (under any snapshot), it produces correct output and the child exits 0, however I see an exception message in the strace output: --- Process 3848, exception C005 at 610E114A (oddliy, the process ID is that of the parent, not the child) -- Running the test program in strace under 1.7.7, I also get a similar exception message in the strace output even though the test program appears to work correctly. -heath -- 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
Problem with fork() in latest snapshot
I have ruby 1.9.2 which I built from source. It works fine in cygwin 1.7.7 and earlier, but in the current snapshot when it does a fork, the child process dies pretty much instantly. I've put together a test case (see attached) which replicates what ruby is doing so that this problem can be repro'd without needing to build ruby. It seems that the failure only happens when the fork call is in a dll, and it also seems to depend on manipulating threads in close proximity to the fork. Here's the test program under 1.7.7: $ uname -a CYGWIN_NT-6.1-WOW64 hkehoe1 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin $ ./testfork Before fork After fork pid=5060 After fork pid=0 subprocess status 0 (0x0) And here it is in the snapshot: $ uname -a CYGWIN_NT-6.1-WOW64 hkehoe1 1.7.8s(0.233/5/3) 20101102 14:03:08 i686 Cygwin $ ./testfork Before fork After fork pid=3808 subprocess status 32512 (0x7f00) Note the missing 'After fork' message from the child and the -127 exit status. An strace of testfork will reveal this error occurring shortly after the fork returns in the child: --- Process 2944, exception C005 at 610E4B8C (the process ID is the child's) __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ testfork.tgz Description: Binary data -- 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: strange crashes on invocation
On 10/1/2010 5:02 PM, Christopher Faylor wrote: On Mon, Sep 27, 2010 at 11:52:12AM -0500, Heath Kehoe wrote: Ugh! spoke too soon. It happened again: 1 [main] bash 5112! C:\cygwin\bin\bash.exe: *** fatal error - could not load C:\Windows\system32\ws2_32.dll, Win32 error 998 Stack trace: Frame Function Args 00288974 6102740B (00288974, , , ) 00288C64 6102740B (61179C40, 8000, , 6117B997) 00289C94 61004B2B (6117B084, 00289CB0, , ) 00289EE4 6100136E (61053A2A, 0154, 0002, 0002) It's definitely a lot less frequent, though. I truly do not understand why playing with the stack should have any effect but I've added a retry loop to the LoadLibrary call after reading some vague MSDN articles which indicated that it could fail mysteriously. So: How about how? http://cygwin.com/snapshots.html cgf Running from CVS from Friday with your retry loop, I still had the same error happen once, so apparently the retry loop didn't help for me. I have since updated CVS to that of today (10/4), and thus far have not seen the error. If it continues to happen, I should be able to take some time this week to create a test case so that others can repro the problem. -h __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: strange crashes on invocation
On 9/24/2010 2:54 PM, Christopher Faylor wrote: On Fri, Sep 24, 2010 at 01:23:48PM -0500, Heath Kehoe wrote: Well, another difference is the addition of PATH_MAX*2 bytes on the stack. Those functions do some stack manipulations that I'm having trouble grokking. Does 'ret' need to be topmost on the stack? As a test, I moved the 'ret' definition after that of 'dll_path' (in std_dll_init). So far with that change, I have not seen the LoadLibrary fatal error, though I need to test it more to be sure. I've moved some other stuff around in that function. Could you try the latest CVS? cgf With your changes, I have not yet encountered any of the error 998 failures, and I've run a couple of rebuilds of my project as a stress-test. Thanks, -h __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: strange crashes on invocation
On 9/27/2010 10:31 AM, Heath Kehoe wrote: On 9/24/2010 2:54 PM, Christopher Faylor wrote: On Fri, Sep 24, 2010 at 01:23:48PM -0500, Heath Kehoe wrote: Well, another difference is the addition of PATH_MAX*2 bytes on the stack. Those functions do some stack manipulations that I'm having trouble grokking. Does 'ret' need to be topmost on the stack? As a test, I moved the 'ret' definition after that of 'dll_path' (in std_dll_init). So far with that change, I have not seen the LoadLibrary fatal error, though I need to test it more to be sure. I've moved some other stuff around in that function. Could you try the latest CVS? cgf With your changes, I have not yet encountered any of the error 998 failures, and I've run a couple of rebuilds of my project as a stress-test. Thanks, -h Ugh! spoke too soon. It happened again: 1 [main] bash 5112! C:\cygwin\bin\bash.exe: *** fatal error - could not load C:\Windows\system32\ws2_32.dll, Win32 error 998 Stack trace: Frame Function Args 00288974 6102740B (00288974, , , ) 00288C64 6102740B (61179C40, 8000, , 6117B997) 00289C94 61004B2B (6117B084, 00289CB0, , ) 00289EE4 6100136E (61053A2A, 0154, 0002, 0002) It's definitely a lot less frequent, though. -h __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: strange crashes on invocation
On 9/24/2010 4:17 AM, Corinna Vinschen wrote: Can you revert to the latest from CVS and try again with this patch applied: Index: autoload.cc === RCS file: /cvs/src/src/winsup/cygwin/autoload.cc,v retrieving revision 1.174 diff -u -p -r1.174 autoload.cc --- autoload.cc 23 Sep 2010 20:18:16 - 1.174 +++ autoload.cc 24 Sep 2010 09:15:40 - @@ -233,7 +233,7 @@ std_dll_init () dll-handle = h; } else if (!(func-decoration 1)) - api_fatal (could not load %W, %E, dll-name); + api_fatal (could not load %W, %E, dll_path); else dll-handle = INVALID_HANDLE_VALUE; } If the error occurs again, what is the path printed in the error message? Is it sane? Does the directory correspond to your local X:\Windows\System32 directory? Done. The crash came back and here's the result: 1 [main] bclanc 2544! C:\budcat\tools\bin\bclanc.exe: *** fatal error - could not load C:\Windows\system32\ws2_32.dll, Win32 error 998 Stack trace: Frame Function Args 00289F34 6102740B (00289F34, , , ) 0028A224 6102740B (6117AC40, 8000, , 6117C997) 0028B254 61004B2B (6117C084, 0028B270, , ) 0028B4A4 6100136E (61053A4A, 0168, 0002, 0002) The path is correct. I have no explanation why changing from a filename to a pathname (and LoadLibrary to LoadLibraryW) would make any difference, unless there's a race condition, say if LoadLibrary[W] is a bit faster when you give it a full path. That's just speculation, of course. But the intermittent nature of this crash (1 in 500ish invocations) would also seem to point to a race condition of some kind. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: strange crashes on invocation
On 9/24/2010 11:57 AM, Corinna Vinschen wrote: On Sep 24 11:31, Heath Kehoe wrote: The path is correct. I have no explanation why changing from a filename to a pathname (and LoadLibrary to LoadLibraryW) would make any difference, unless there's a race condition, say if LoadLibrary[W] is a bit faster when you give it a full path. That doesn't make sense. It's the LoadLibraryW call itself which is failing with error 998, Invalid access to memory location. Hmm. Puzzeling. Well, another difference is the addition of PATH_MAX*2 bytes on the stack. Those functions do some stack manipulations that I'm having trouble grokking. Does 'ret' need to be topmost on the stack? As a test, I moved the 'ret' definition after that of 'dll_path' (in std_dll_init). So far with that change, I have not seen the LoadLibrary fatal error, though I need to test it more to be sure. -h __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: strange crashes on invocation
On 9/23/2010 12:13 PM, Heath Kehoe wrote: I have a build system that uses rake under cygwin, and every so often a build tool will crash on invocation: 1 [main] bclanc 1576! C:\budcat\tools\bin\bclanc.exe: *** fatal error - could not load w, Win32 error 998 Stack trace: Frame Function Args 00289F44 6102740B (00289F44, , , ) 0028A234 6102740B (61179C20, 8000, , 6117B997) 0028B264 61004B2B (6117B084, 61163DD0, , ) 0028B4C4 6100137A (61053A9A, 0168, 0002, 0002) [snip] My OS is Win7 x64. Cygwin is built from CVS as of 2010-09-21 12:11 (though I'm pretty sure I've seen this on 1.7.7 as well) I've confirmed that this crash is happening on 1.7.7; it does not appear to happen on 1.7.6. Could it be related to the DLL loading change relating to the security advisory? I'll probably try to revert the revision 1.171 changes to autoload.cc to see if that makes any difference. -h __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: strange crashes on invocation
On 9/23/2010 3:07 PM, Heath Kehoe wrote: On 9/23/2010 12:13 PM, Heath Kehoe wrote: I have a build system that uses rake under cygwin, and every so often a build tool will crash on invocation: 1 [main] bclanc 1576! C:\budcat\tools\bin\bclanc.exe: *** fatal error - could not load w, Win32 error 998 Stack trace: Frame Function Args 00289F44 6102740B (00289F44, , , ) 0028A234 6102740B (61179C20, 8000, , 6117B997) 0028B264 61004B2B (6117B084, 61163DD0, , ) 0028B4C4 6100137A (61053A9A, 0168, 0002, 0002) [snip] My OS is Win7 x64. Cygwin is built from CVS as of 2010-09-21 12:11 (though I'm pretty sure I've seen this on 1.7.7 as well) I've confirmed that this crash is happening on 1.7.7; it does not appear to happen on 1.7.6. Could it be related to the DLL loading change relating to the security advisory? I'll probably try to revert the revision 1.171 changes to autoload.cc to see if that makes any difference. I'm currently testing the latest CVS, but with these changes rolled back: http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/autoload.cc.diff?r1=1.170r2=1.171cvsroot=srcf=h Thus far, I have not yet seen the crash. I'll hammer on it more to make sure. BTW, that stack trace's addresses correspond to: cygwin_stackdump cygwin_stackdump __api_fatal std_dll_init Which is unsurprising and also not very informative (I'd already found where the fatal error was coming from by searching for could not load in the sources). When looking at the autoload.cc code, I noticed the api_fatal call is still using dll-name as an ascii string when revision 1.171 changed dll-name to a wide string. That's why the error message only prints the first character of the dll name. -h __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: Problem with mmap in latest snapshot
On 9/21/2010 11:48 AM, Corinna Vinschen wrote: I've checked in the patch. Please test the next developer snapshot. Thanks again for the testcase. It was very helpful. I built from CVS and it's working again. Thanks! -h __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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
Problem with mmap in latest snapshot
My application uses mmap on a 16MB file. On released 1.7.7, there's no
problem. But with the 20100919 snapshot, it crashes when it tries to
access the mmap space past the first 32KB or so. Attached is a simple
test program that illustrates the problem.
* With 1.7.7 *
$ uname -a
CYGWIN_NT-6.1-WOW64 hkehoe1 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
$ ./a
creating mmap-test-file
Writing zeros
mmap-ing
writing ones to mmap region
done!
$ ls -l mmap*
-rw-r--r--+ 1 hkehoe Domain Users 16777216 2010-09-20 14:51 mmap-test-file
$ od -tc mmap-test-file
000 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001
*
1
* With snapshot *
$ uname -a
CYGWIN_NT-6.1-WOW64 hkehoe1 1.7.8s(0.231/5/3) 20100919 16:19:37 i686 Cygwin
$ ./a
creating mmap-test-file
Writing zeros
mmap-ing
writing ones to mmap region
Segmentation fault (core dumped)
$ od -tc mmap-test-file
000 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001
*
010 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
1
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__#include stdio.h
#include stdlib.h
#include string.h
#include sys/types.h
#include fcntl.h
#include sys/mman.h
#define MMAP_FILE mmap-test-file
#define MMAP_SIZE 16384*1024
main()
{
int fd;
char* maddr;
printf(creating MMAP_FILE \n);
fd = open(MMAP_FILE, O_CREAT|O_TRUNC|O_RDWR, 0666);
if(fd 0)
{
perror(Could not open MMAP_FILE);
exit(1);
}
printf(Writing zeros\n);
{
int n = MMAP_SIZE;
char buf[1024];
memset(buf, 0, 1024);
while(n 0)
{
write(fd, buf, 1024);
n -= 1024;
}
}
printf(mmap-ing\n);
maddr = mmap(NULL, MMAP_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if(maddr == NULL || maddr == MAP_FAILED)
{
perror(mmap);
exit(1);
}
printf(writing ones to mmap region\n);
{
int n;
for(n = 0; n MMAP_SIZE; n++)
maddr[n] = 1;
}
printf(done!\n);
}
--
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: Problem with mmap in latest snapshot
On 9/20/2010 3:00 PM, Heath Kehoe wrote: My application uses mmap on a 16MB file. On released 1.7.7, there's no problem. But with the 20100919 snapshot, it crashes when it tries to access the mmap space past the first 32KB or so. Attached is a simple test program that illustrates the problem. The test program also crashes on 20100917, but it works with 20100912. -h __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: Behaviours of Terminal Versus Script when using
On 9/15/2010 12:18 PM, delbydev wrote:
Hello
Have hunted all over for this one but it seems no one else has reported the
issue - maybe because they don't use the feature or there is something awry
with my installation
I write scripts that dart in and out of databases
I bind my Oracle connection string into a number of variables in my .profile
ORACLE_HOME='c:\\Oracle\\product\\11.2.0\\dbhome_2' export ORACLE_HOME
mydbconn=${ORACLE_HOME}\\bin\\sqlplus -s mydbuser/mydbp...@mydbhost export
mydbconn
[snip]
so two questions
1) Does the MS CMD Terminal support in scripts (presently not in my
installation) - I can't be sure but I think it used to work on older
environment
2) Is minnty a default standard terminal that will ship with all future
builds of cygwin?
The problem here is not in the construct. That's a function of the
bash shell, not the terminal window (cmd, mintty), and works the same
way in both.
I'll bet the problem is your $mydbconn variable is not set where you're
trying to run your script. Try this test... in your script, put:
echo mydbconn is set to ${mydbconn}. /tmp/myresults.txt
And run it. I'll bet you'll see mydbconn is set to . which means it's
empty (not set) when using cmd, and is set when using mintty.
The reason is that you put those variable settings in .profile, which is
only used in login shells; and whether a shell is a login shell
depends on how it is invoked; which can differ depending on the terminal
window you use and how *that* is invoked.
Try placing your mydbconn and ORACLE_HOME variable settings into .bashrc
instead of (or in addition to) your .profile; or directly into your script.
-h
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
--
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: How to get a script file to use bash and ssh
On 9/2/2010 2:10 PM, PaulHR wrote:
I want to create script files that are not bound to my user id. I want to
create over 20 different scripts files, one for each server I manage. I
have uploaded keys to each server. So all I should have to is enter is the
ssh command
I have put in a file called MyOpenUp.bat the following...
ssh {myserve...@myserverhostname}
I have put that command in a file called MyOpenUp.init
I have created a MyOpenUp.bat file with the following
@echo off
C:
chdir C:\cygwin\bin
bash --init-file MyOpenUp.init -i -l
That's all more complicated than it needs to be. Just make windows
shortcuts to c:\cygwin\bin\ssh.exe, where Start in: is set to
c:\cygwin\bin, and modify Target: to contain C:\cygwin\bin\ssh.exe
usern...@hostname (without the quotes of course).
Better yet, install mintty if you don't already have it, and set the
shortcuts' target to: C:\cygwin\bin\mintty.exe -e /bin/ssh
usern...@hostname
(Mintty is a much better term window than cmd.)
-heath
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
--
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 slow on x64 systems
On 9/1/2010 2:10 PM, Christopher Faylor wrote: I rewrote the signal initialization stuff today and have generated a new snapshot. Please let me know if this works better for you. I haven't actually tried to run a fork per sec. test yet so there may be other lurking problems. http://cygwin.com/snapshots/ On my Win7 x64 system, this snapshot (2010-09-01) doesn't work. Cygwin commands fail to start without any output; and strace just outputs a short exception message: c:\cygwin\binbash c:\cygwin\binstrace bash --- Process 872, exception C005 at 6100600B c:\cygwin\bin If I put the original cygwin1.dll (1.7.7) back, everything works again. I also have sources, and built the latest from CVS, and that cygwin1.dll fails in the same way. -heath __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: mbox note: Can't open file://L:\ods\rtoy\Cygnus/ for reading: Unrecognisable file format errors whilst executing setup.exe
Heath Kehoe wrote: - Using setup.exe version 2.677 - We have a local mirror which is updated using rsync (daily) - The local mirror is accessed as a network share on the Windows machines, which is mapped to a drive letter. - In setup.exe, select 'Install from Local Directory' - The root directory is: C:\cygwin - Install for: All users - Local package directory for us is: M:\apps\cygwin (the network share) - Select all packages to install (if it's a new installation. For an upgrade we take the default selections) - During the installation, we get pop-ups that say can't open M:\apps\cygwin for reading: Unrecognisable file format. Those pop-ups must be dismissed for the installation to finish, and they happen many times (52 times for a new, full installation) - Once setup is complete, Cygwin appears to work OK. - We've observed this on both fresh new installations as well as with upgrades from 1.5 - We've observed this on Win7 64bit and on XP 32bit. These lines appear throughout setup.log.full and correspond to the popups: 2010/01/27 17:27:12 mbox note: Can't open file://M:\apps\cygwin\Current/ for reading: Unrecognisable file format Hopefully this is enough detail :) -heath I have some more information on this. The errors correspond to packages which are in setup.ini without install: or source: lines, for example: ORBit cogito libIDL libxml-devel libxml1 (etc) These packages wind up in install_q in do_install_thread(); and so get passed to Installer::installOne(). As there's no 'install:' field in setup.ini, the packagesource 'filename' and 'canonical' members are NULL; and the 'cached' member ends up containing 'local_dir' with nothing else; hence the mbox message that we see. I'm not sure why this only seems to manifest when using a network drive as the package source (or cache). Anyway, for now I'm going to just comment out the call to note() at install.cc:295 so that my users can do installations without having to dismiss that popup 52 times. -heath __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: mbox note: Can't open file://L:\ods\rtoy\Cygnus/ for reading: Unrecognisable file format errors whilst executing setup.exe
Jeremy Bopp wrote: True enough, and hopefully Heath will send along the patches to fix the problem. It just seems in this case that distributing a locally built setup.exe is a bit like hammering a finishing nail with a sledge hammer. Yeah, it works, but it takes far more effort than required to do the job. :-) -Jeremy I'm not going to send a patch because I only commented out a line of code (and I said which file and line number it was, so anyone with the source can do the same), and it doesn't fix the root problem: it only suppresses an error message popup. It does make setup.exe usable again in our environment. Since my users run setup.exe from the network drive, all I had to do was drop in the custom one. I hope my description of what was going on in the code is enough for the maintainers to be able to implement a proper fix. -h __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: mbox note: Can't open file://L:\ods\rtoy\Cygnus/ for reading: Unrecognisable file format errors whilst executing setup.exe
Richard Toy wrote: Both at work and home I install Cygwin on several machines and I keep a local cache of the Cygwin install files to reduce the time to update. I always run setup.exe and perform a full install of everything. Since upgrading to the latest version of setup, when performing the local install from the local cache I get apparently random warning boxes with the following error text: - Can't open file://L:\ods\rtoy\Cygnus/ for reading: Unrecognisable file format. The boxes (51 occurences) can be simply clicked away and the install completes. Once complete a check of the installation (cygcheck -cv) shows that it is complete (all OK) The same error occurs in both the work (Windows XP) and home (Windows 7) environments. In both cases the local cache is accessed through a mapped network drive. [snip] Has anyone else seen this? Richard We're seeing the same issue. We have a mirror of the cygwin tree (which is updated through rsync) which is made available on a network share, mapped to a drive letter. When running setup we pick 'Install from Local Directory' and usually select all packages. And we too get a bunch of those 'Unrecognisable file format' popups. Makes installation a pain as those popup errors all have to be dismissed for the install process to continue. -heath __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: mbox note: Can't open file://L:\ods\rtoy\Cygnus/ for reading: Unrecognisable file format errors whilst executing setup.exe
Christopher Faylor wrote: On Wed, Jan 27, 2010 at 03:24:38PM -0600, Heath Kehoe wrote: [snip] We're seeing the same issue. We have a mirror of the cygwin tree (which is updated through rsync) which is made available on a network share, mapped to a drive letter. When running setup we pick 'Install from Local Directory' and usually select all packages. And we too get a bunch of those 'Unrecognisable file format' popups. Makes installation a pain as those popup errors all have to be dismissed for the install process to continue. If you want to get a problem fixed, the way to do it is to provide details, not commiseration. What version of setup.exe are you running? What specific steps are necessary to duplicate the problem? cgf Wasn't meant to be commiserative. I went to report this issue and did a search first to see if anyone else has seen it. - Using setup.exe version 2.677 - We have a local mirror which is updated using rsync (daily) - The local mirror is accessed as a network share on the Windows machines, which is mapped to a drive letter. - In setup.exe, select 'Install from Local Directory' - The root directory is: C:\cygwin - Install for: All users - Local package directory for us is: M:\apps\cygwin (the network share) - Select all packages to install (if it's a new installation. For an upgrade we take the default selections) - During the installation, we get pop-ups that say can't open M:\apps\cygwin for reading: Unrecognisable file format. Those pop-ups must be dismissed for the installation to finish, and they happen many times (52 times for a new, full installation) - Once setup is complete, Cygwin appears to work OK. - We've observed this on both fresh new installations as well as with upgrades from 1.5 - We've observed this on Win7 64bit and on XP 32bit. These lines appear throughout setup.log.full and correspond to the popups: 2010/01/27 17:27:12 mbox note: Can't open file://M:\apps\cygwin\Current/ for reading: Unrecognisable file format Hopefully this is enough detail :) -heath __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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
