Re: Cygwin making files inaccessible?
I looked at this a while. I tried various recent cygwin1.dlls as there were two ACL changes recently. I tried building cygwin1.dll with those changes reverted, but failed to build it. For one thing it took me a while to find shilka..it is in cocom, but that wasn't the entire problem. Eventually.. I noticed the behavior was not the same for every file/directory/volume. Sometimes it worked ok. Though I think the ACLs still get changed quite a bit: "full" expands to "many". Of course it has worked plenty for me and everyone else. Eventually I tried chmod -R 777 * and this seems to have worked. I speculate that some "bad" Cygwin ACLs got created at some point. And maybe cacls wasn't deleting them?? That parts seems wierd. Maybe on directories? Possibly due to those two recent changes, or maybe user error, I don't know. - Jay From: Jay K Sent: Saturday, February 5, 2022 12:16 PM To: cygwin@cygwin.com Subject: Cygwin making files inaccessible? Cygwin making files inaccessible? i.e. when Cygwin copies or writes to them, not random files. C:\t>dir /s/b/a C:\t>dir /q . 02/05/2022 04:11 AM BUILTIN\Administrators . 02/05/2022 04:11 AM NT SERVICE\TrustedInsta.. C:\t>cacls . C:\t Everyone:(OI)(CI)F C:\t>echo > 1.txt C:\t>cacls 1.txt C:\t\1.txt Everyone:F C:\t>copy 1.txt 2.txt 1 file(s) copied. C:\t>cacls 2.txt C:\t\2.txt Everyone:F C:\t>del 2.txt C:\t>uname -a CYGWIN_NT-10.0-WOW DESKTOP-BCFUMJ4 3.3.4(0.341/5/3) 2022-01-31 19:31 i686 Cygwin C:\t>cp 1.txt 2.txt C:\t>which cp /usr/bin/cp C:\t>cacls 2.txt C:\t\2.txt NULL SID:(DENY)(special access:) READ_CONTROL DESKTOP-BCFUMJ4\jay:(DENY)(special access:) FILE_READ_DATA FILE_READ_EA FILE_EXECUTE DESKTOP-BCFUMJ4\jay:(special access:) STANDARD_RIGHTS_ALL DELETE READ_CONTROL WRITE_DAC WRITE_OWNER SYNCHRONIZE STANDARD_RIGHTS_REQUIRED FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES DESKTOP-BCFUMJ4\None:R Everyone:R C:\t>more 1.txt ECHO is on. C:\t>more 2.txt Cannot access file C:\t\2.txt Same behavior from cygwin64. C:\t>\cygwin64\bin\uname -a CYGWIN_NT-10.0 DESKTOP-BCFUMJ4 3.3.3(0.341/5/3) 2021-12-03 16:35 x86_64 Cygwin Huh? I would hope Cygwin could/would just copy the ACLs asis. I am guessing there is some failed attempt to translate them to an internal form and then back to NT form. My real scenario was open/write/read, not cp.exe. - Jay -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Cygwin making files inaccessible?
Cygwin making files inaccessible? i.e. when Cygwin copies or writes to them, not random files. C:\t>dir /s/b/a C:\t>dir /q . 02/05/2022 04:11 AM BUILTIN\Administrators . 02/05/2022 04:11 AM NT SERVICE\TrustedInsta.. C:\t>cacls . C:\t Everyone:(OI)(CI)F C:\t>echo > 1.txt C:\t>cacls 1.txt C:\t\1.txt Everyone:F C:\t>copy 1.txt 2.txt 1 file(s) copied. C:\t>cacls 2.txt C:\t\2.txt Everyone:F C:\t>del 2.txt C:\t>uname -a CYGWIN_NT-10.0-WOW DESKTOP-BCFUMJ4 3.3.4(0.341/5/3) 2022-01-31 19:31 i686 Cygwin C:\t>cp 1.txt 2.txt C:\t>which cp /usr/bin/cp C:\t>cacls 2.txt C:\t\2.txt NULL SID:(DENY)(special access:) READ_CONTROL DESKTOP-BCFUMJ4\jay:(DENY)(special access:) FILE_READ_DATA FILE_READ_EA FILE_EXECUTE DESKTOP-BCFUMJ4\jay:(special access:) STANDARD_RIGHTS_ALL DELETE READ_CONTROL WRITE_DAC WRITE_OWNER SYNCHRONIZE STANDARD_RIGHTS_REQUIRED FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES DESKTOP-BCFUMJ4\None:R Everyone:R C:\t>more 1.txt ECHO is on. C:\t>more 2.txt Cannot access file C:\t\2.txt Same behavior from cygwin64. C:\t>\cygwin64\bin\uname -a CYGWIN_NT-10.0 DESKTOP-BCFUMJ4 3.3.3(0.341/5/3) 2021-12-03 16:35 x86_64 Cygwin Huh? I would hope Cygwin could/would just copy the ACLs asis. I am guessing there is some failed attempt to translate them to an internal form and then back to NT form. My real scenario was open/write/read, not cp.exe. - Jay -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ExitProcess does not work in Cygwin?
> It is best to avoid Cygwin-specific code. Agreed. The code is mostly only ifdef win32 vs. Posix but just a few spots are Cygwin-specific. (and Apple specific, Solaris specific, IA64-specific etc.) - Jay From: Andrey Repin Sent: Wednesday, January 26, 2022 2:23 PM To: Jay K ; cygwin@cygwin.com Subject: Re: ExitProcess does not work in Cygwin? Greetings, Jay K! >> Just use POSIX exit(3)! > I did switch my code: > #ifdef __CYGWIN__ > exit(x); > #else > ExitProcess(x); > #endif > . It is best to avoid Cygwin-specific code. Use either Linux(POSIX) or Windows specific tests, and only test for Cygwin if /absolutely/ necessary. -- With best regards, Andrey Repin Wednesday, January 26, 2022 17:22:01 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ExitProcess does not work in Cygwin?
> Just use POSIX exit(3)! I did switch my code: #ifdef __CYGWIN__ exit(x); #else ExitProcess(x); #endif . I think the problem is actually in how "Cygwin bash" aka Cygwin, computes the exit code in exec/spawn/system. I.e. it recognizes it is running a Cygwin exe or a native exe and does things differently. I admit I didn't read or debug much. In one run I was debugging I did seem to see a crash in some DllMain(process detach), without symbols, and then I seemed to see ExitProcess(1 or 2) become ExitProcess(0xXX00) and then I started wondering if Cygwin somewhere is only taking the lower 8 bits, since I know that is a thing in some code. But I didn't dig into this further before trying the simple case, which I don't think crashes and really does NtTerminateProcess(1). - Jay From: Brian Inglis Sent: Thursday, January 13, 2022 5:19 PM To: cygwin@cygwin.com Cc: Jay K Subject: Re: ExitProcess does not work in Cygwin? On 2022-01-13 10:07, Kaz Kylheku (Cygwin) wrote: > On 2022-01-13 05:40, Eliot Moss wrote: >> On 1/13/2022 1:39 AM, Jay K wrote: >>> ExitProcess does not work in Cygwin? Just use POSIX exit(3)! >> ExitProcess does not appear to be a POSIX function. > > This is a real issue worth looking into. Though ExitProcess isn't a POSIX > function, Cygwin can capture the termination status of non-Cygwin programs. > > The concept of termination status cannot be entirely walled off in a > private Cygwin garden; it belongs to the underlying platform. > > In Cygwin, I can do this: > >C:\Cygwin\cygwin64\home\kaz>exit 1 >1:BLACKBOX:~$ >1:BLACKBOX:~$ echo $? >1 >0:BLACKBOX:~$ cmd >Microsoft Windows [Version 10.0.19042.1052] >(c) Microsoft Corporation. All rights reserved. > >C:\Cygwin\cygwin64\home\kaz>exit 0 >0:BLACKBOX:~$ > > The number in my Bash prompt is the last exit code. As you can see, > the non-Cygwin CMD.EXE program produces a termination code which > is recognized in the Cygwin world. > > Most likely it does that via ExitProcess. > > It is odd if calling ExitProcess in a Cygwin process causes > a Cygwin parent not to similarly process the status, as seems > to be shown by Jay's test cases. > > Cygwin supports non-POSIX programming; you can write GUI applications > using Win32 calls for instance. > > (Now I agree that for exiting your process, even if it's a GUI > application using numerous win32 calls, you should probably do it the > Cygwin way, and use exit, or return from main. But still ...) Cygwin installs at-exit handlers and it is likely that when these have finished, they return a Cygwin exit status if passed by the POSIX function, perhaps unless some error has occurred during at-exit handling. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
I don't know why I didn't get the reply in email, but this is representative of
the real world code.
- Jay
From: Jay K
Sent: Wednesday, January 12, 2022 6:27 AM
To: cyg...@sourceware.org
Subject: Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
Ok, here is a small demonstration of the problem.
#include
#include
#include
unsigned __stdcall thread(void* p)
{
unsigned i;
for (i = 0; i < 100; ++i)
system("./a.exe");
return 0;
}
int main()
{
unsigned i;
HANDLE threads[100] = {0};
FILE* f = fopen("a.c", "w");
fprintf(f, "int main() { return 0; }\n");
fclose(f);
system("g++ a.c");
for (i = 0; i < 100; ++i)
threads[i] = CreateThread(0, 0, thread, 0,0,0);
for (i = 0; i < 100; ++i)
WaitForSingleObject(threads[i], -1);
}
$ ./1.exe
0 [main] sh 9287 C:\cygwin64\bin\sh.exe: *** fatal error - internal error
reading the windows environment - too many environment variables?
3001 [main] sh 9287
cygwin_exception::open_stackdumpfile: Dumping stack trace to sh.exe.stackdump
0 [main] sh 9286
C:\cygwin64\bin\sh.exe: *** fatal error - internal error reading the windows
environment - too many environment variables?
Stack trace:
Frame Function Args
000CD30 00180061C6E (001802795F0, 00180269E81, 000, 000BB20)
000CD30 0018004849A (228, 0080160, 000, 000CD30)
000CD30 001800484D2 (000, 000, 000, 000)
000CD30 0018005F12D (00180158C19, 000, 000, 000CD30)
000CD30 00180103AE4 (000, 000, 000, 000)
000CD30 00180048BC2 (000, 000, 000, 000)
000FFF0 00180047746 (000, 000, 000, 000)
000FFF0 001800477F4 (000, 000, 000, 000)
End of stack trace
0 [waitproc] 1 9269 proc_waiter: error on read of child
wait pipe 0x0, Win32 error 6
1078 [waitproc] 1 9269 proc_waiter: error on read of child wait
pipe 0x0, Win32 error 6
4452 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
sh: ./a.exe: Bad address
11522 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
sh: ./a.exe: Bad address
sh: ./a.exe: Bad address
38623 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
48009 [waitproc] 1 9269 proc_waiter: error on read of child wait
pipe 0x0, Win32 error 6
48660 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
49909 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
I understand I can workaround this, in that the use of threads is silly.
Is this invalid, to mix Win32 threads with cygwin system()?
- Jay
From: Jay K
Sent: Wednesday, January 12, 2022 5:57 AM
To: cyg...@sourceware.org
Subject: Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
Um, I know this isn't (yet) diligent/scientific, but must system create this
thread?
#0 0x7ff811e09e47 in KERNEL32!CreateThread () from
/cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#1 0x0001800468eb in cygthread::create() () from /usr/bin/cygwin1.dll
#2 0x00018010645f in pinfo::wait() () from /usr/bin/cygwin1.dll
#3 0x00018012e562 in proc_subproc(unsigned int, unsigned long) () from
/usr/bin/cygwin1.dll
#4 0x000180134e85 in child_info_spawn::worker(char const*, char const*
const*, char const* const*, int, int, int) () from /usr/bin/cygwin1.dll
#5 0x000180136729 in spawnve () from /usr/bin/cygwin1.dll
#6 0x000180136d05 in spawnvp () from /usr/bin/cygwin1.dll
#7 0x000180144683 in system () from /usr/bin/cygwin1.dll
#8 0x00018018effb in _sigfe () from /usr/bin/cygwin1.dll
#9 0x00010052884b in QMachine__ExecCommand (t_L_563=0x448ef0
"\260\324\005",
'cause i.e. it complicates any lifetime/management.
I do understand some of the problems here, like needing separate threads to
read stdout/stderr, if they are not equal.
- Jay
From: Jay K
Sent: Wednesday, January 12, 2022 4:12 AM
To: cyg...@sourceware.org
Subject: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
I get t
ExitProcess does not work in Cygwin?
ExitProcess does not work in Cygwin?
$ rm *.exe
# u is for Unix
# w is for Windows
$ cat u.c
#include
int main()
{
exit(1);
}
$ gcc u.c
$ ./a.exe
$ echo $?
1
=> as expected
$ cat w.c
#include
int main()
{
ExitProcess(1);
}
$ gcc w.c
$ ./a.exe
$ echo $?
0
=> not expected
$ uname -a
CYGWIN_NT-10.0 jayk-tp4 3.3.3(0.341/5/3) 2021-12-03 16:35 x86_64 Cygwin
works in debugger:
$ /cygdrive/c/bin/amd64/windbg.exe .\\a.exe
$ echo $?
1
?
- Jay
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
Ok, here is a small demonstration of the problem.
#include
#include
#include
unsigned __stdcall thread(void* p)
{
unsigned i;
for (i = 0; i < 100; ++i)
system("./a.exe");
return 0;
}
int main()
{
unsigned i;
HANDLE threads[100] = {0};
FILE* f = fopen("a.c", "w");
fprintf(f, "int main() { return 0; }\n");
fclose(f);
system("g++ a.c");
for (i = 0; i < 100; ++i)
threads[i] = CreateThread(0, 0, thread, 0,0,0);
for (i = 0; i < 100; ++i)
WaitForSingleObject(threads[i], -1);
}
$ ./1.exe
0 [main] sh 9287 C:\cygwin64\bin\sh.exe: *** fatal error - internal error
reading the windows environment - too many environment variables?
3001 [main] sh 9287
cygwin_exception::open_stackdumpfile: Dumping stack trace to sh.exe.stackdump
0 [main] sh 9286
C:\cygwin64\bin\sh.exe: *** fatal error - internal error reading the windows
environment - too many environment variables?
Stack trace:
FrameFunctionArgs
000CD30 00180061C6E (001802795F0, 00180269E81, 000, 000BB20)
000CD30 0018004849A (228, 0080160, 000, 000CD30)
000CD30 001800484D2 (000, 000, 000, 000)
000CD30 0018005F12D (00180158C19, 000, 000, 000CD30)
000CD30 00180103AE4 (000, 000, 000, 000)
000CD30 00180048BC2 (000, 000, 000, 000)
000FFF0 00180047746 (000, 000, 000, 000)
000FFF0 001800477F4 (000, 000, 000, 000)
End of stack trace
0 [waitproc] 1 9269 proc_waiter: error on read of child
wait pipe 0x0, Win32 error 6
1078 [waitproc] 1 9269 proc_waiter: error on read of child wait
pipe 0x0, Win32 error 6
4452 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
sh: ./a.exe: Bad address
11522 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
sh: ./a.exe: Bad address
sh: ./a.exe: Bad address
38623 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
48009 [waitproc] 1 9269 proc_waiter: error on read of child wait
pipe 0x0, Win32 error 6
48660 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
49909 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
I understand I can workaround this, in that the use of threads is silly.
Is this invalid, to mix Win32 threads with cygwin system()?
- Jay
From: Jay K
Sent: Wednesday, January 12, 2022 5:57 AM
To: cyg...@sourceware.org
Subject: Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
Um, I know this isn't (yet) diligent/scientific, but must system create this
thread?
#0 0x7ff811e09e47 in KERNEL32!CreateThread () from
/cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#1 0x0001800468eb in cygthread::create() () from /usr/bin/cygwin1.dll
#2 0x00018010645f in pinfo::wait() () from /usr/bin/cygwin1.dll
#3 0x00018012e562 in proc_subproc(unsigned int, unsigned long) () from
/usr/bin/cygwin1.dll
#4 0x000180134e85 in child_info_spawn::worker(char const*, char const*
const*, char const* const*, int, int, int) () from /usr/bin/cygwin1.dll
#5 0x000180136729 in spawnve () from /usr/bin/cygwin1.dll
#6 0x000180136d05 in spawnvp () from /usr/bin/cygwin1.dll
#7 0x000180144683 in system () from /usr/bin/cygwin1.dll
#8 0x00018018effb in _sigfe () from /usr/bin/cygwin1.dll
#9 0x00010052884b in QMachine__ExecCommand (t_L_563=0x448ef0
"\260\324\005",
'cause i.e. it complicates any lifetime/management.
I do understand some of the problems here, like needing separate threads to
read stdout/stderr, if they are not equal.
- Jay
From: Jay K
Sent: Wednesday, January 12, 2022 4:12 AM
To: cyg...@sourceware.org
Subject: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
I get this a lot:
0 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
452 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
716 [waitproc] cm3 7641 proc
Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
Um, I know this isn't (yet) diligent/scientific, but must system create this thread? #0 0x7ff811e09e47 in KERNEL32!CreateThread () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL #1 0x0001800468eb in cygthread::create() () from /usr/bin/cygwin1.dll #2 0x00018010645f in pinfo::wait() () from /usr/bin/cygwin1.dll #3 0x00018012e562 in proc_subproc(unsigned int, unsigned long) () from /usr/bin/cygwin1.dll #4 0x000180134e85 in child_info_spawn::worker(char const*, char const* const*, char const* const*, int, int, int) () from /usr/bin/cygwin1.dll #5 0x000180136729 in spawnve () from /usr/bin/cygwin1.dll #6 0x000180136d05 in spawnvp () from /usr/bin/cygwin1.dll #7 0x000180144683 in system () from /usr/bin/cygwin1.dll #8 0x00018018effb in _sigfe () from /usr/bin/cygwin1.dll #9 0x00010052884b in QMachine__ExecCommand (t_L_563=0x448ef0 "\260\324\005", 'cause i.e. it complicates any lifetime/management. I do understand some of the problems here, like needing separate threads to read stdout/stderr, if they are not equal. - Jay ________ From: Jay K Sent: Wednesday, January 12, 2022 4:12 AM To: cyg...@sourceware.org Subject: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 I get this a lot: 0 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 452 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 716 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 1652 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 0 [main] sh 7775 C:\cygwin64\bin\sh.exe: *** fatal error - internal error reading the windows environment - too many environment variables? Scenario is multi-threaded "launching" a bunch of invocations of gcc. "launching" was usually spawnve or fork/execve but I changed the code to use system and it still happens. I might try to make a small reproducing, if this is not known. It seems a bit difficult to believe I could cause this internal looking error. Thank you, - Jay -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
I get this a lot: 0 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 452 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 716 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 1652 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 0 [main] sh 7775 C:\cygwin64\bin\sh.exe: *** fatal error - internal error reading the windows environment - too many environment variables? Scenario is multi-threaded "launching" a bunch of invocations of gcc. "launching" was usually spawnve or fork/execve but I changed the code to use system and it still happens. I might try to make a small reproducing, if this is not known. It seems a bit difficult to believe I could cause this internal looking error. Thank you, - Jay -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
fast/native fork?
I have some desire to discuss fork. I know it is an old and difficult topic. I found this: "Cygwin fork and RtlCloneUserProcess" https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/afdf1b68-1f3e-47f5-94cf-51e397afe073/cygwin-fork-and-rtlcloneuserprocess?forum=windowsgeneraldevelopmentissues NT has had fork since v1. The Posix subsystem used it. You didn't need Vista's introduction of RtlCloneUserProcess. This from 2005 alludes to how to make it work: https://www.winvistatips.com/threads/question-about-ntcreateprocess.186504/ but I have difficult questions for you -- anyone, but including Corinna. What do you expect it to do? I mean, consider that there is no pthread_atfork or an analog in Win32. Dlls at all levels of the Win32 stack, might have process-specific state, that needs to be reinitialized. Maybe they were holding locks in a worker thread. Maybe they had the pid cached. Dumb, but it works w/o fork. The usual problems that pthread_atfork is meant to solve. Which memory do you expect to be inherited copy on write, and which memory do you expect to revert to whatever it is when a process starts (or a dll is loaded)? You could hope for something like calling DllMain(process attach) of all the dlls could help, but it can't, at least because dlls just depend on the default data in the image, they don't write the defaults to memory at every load. ntdll.dll is special. It somehow knows fork occured and can reinitialize itself. ntdll.dll is special -- it used by the Posix subsystems (SFU/SUA/Interix/etc.) and always had to work with fork. (Up until Windows 10 and changes for WSL, ntdll.dll was loaded into all usermode processes: Win32, Posix, OS/2. This was specifically changed for WSL.) But no other dll expects this. Now, I have some wierd ideas. Let's brainstorm a little? Can you somehow leave the child process in limbo waiting for exec, know when you have waited too long (because *anything* else happened) and only then do the expensive copying? Or there is the very problem of getting to the exec call and having the exec parameters? I mean, what if you actually knew 100% that exec would come very soon after fork? What would/could you do then? And when exec does not follow, what do you do? How much of the child process is inherited from the parent, vs. how much is reinitialized such as for a new process? If there a solution that optimizes the guaranteed to exec case, can you almost just assume it? Breaking the rare (?) program that does not exec? You could even omit fork. You'd have fork_slow and fork_before_exec. People would have to ifdef Cygwin and chose what they want. Or the default could be fork_before_exec, breaking a small number of programs, that could be easily ported. Ok, how about this? Can you implement exec using only ntdll.dll, avoiding kernel32.dll? And the small/zero number of other things valid/used between fork and exec? And assume exec follows fork? If so then that is a solution: learn how to use native fork and have exec only use ntdll.dll That will give you a fast fork + exec sequence. Or, can you in the new process, just reinitialize kernel32.dll and kernelbase.dll, and only use them for exec? It doesn't do anything for fork without exec but I still don't understand how that is supposed to work in Win32. Or how about this: Again, if you assume exec is coming, and you just need fork to do the minimum -- basically to get a pid. fork calls CreateProcess, with a helper .exe, suspended fork calls CreateThread, passing it the register context of the creating thread the helper thread suspends the creating thread, and takes over its register context (including rip and rsp, approximately), shortly thereafter the helper thread in the creating process reaches exec. At this point, somehow, it adjusts everything..hand waving. How do you implement exec today? Does fork actually get the pid of the new child, and exec in the child somehow "replaces" the executable, or does exec create a second child, with another pid, and the original child just waits for it, and returns its exit code as its own? Or do you have indirection on pids, and cygwin pids are not win32 pids? Oh, that's right, setjmp/longjmp. fork calls setjmp in the parent. The first return continues until exec in the parent and then returns the new pid the second time? Given an arrival at exec, in the parent instead of the child, the usual child part of fork need never run at all. To repeat: To what extent, if any, can we assume exec follows fork? And what can be done with this idea? I understand the more general model, where exec does not follow fork. But how common is it? How would Cygwin fair if by default fork+exec was fast, fork w/o exec didn't work, and people ported those somehow? Fyi: https://mikeash.com/pyblog/friday-qa-2012-01-20-fork-safety.html - Jay -- Problem reports: http://cygwin.com/problems.html
RE: upper limit to df reported available size?
> I guess what we really need > is to redefine fsblkcnt_t to become a 64 bit type. Oh well, this > requires another backward compatibility hack, just like back when we > switched to 64 bit off_t (Cygwin 1.5). Let's do it at the same time as > we change sigset_t and time_t to 64-bits(with knock-on effects to > struct stat, among others). In other words,all good changes, but certainly > something that will take a lot ofplanning to pull off in one go. Can you fix the jmp_buf size then too maybe? It is blown up by a factor of 4. http://sourceware.org/ml/cygwin/2009-01/msg00863.html I realize it has less/no value to fixing. But I'm not sure how changing the others won't require *everything* (just about) to be recompiled anyway. Maybe you rename functions somehow? Thanks, - Jay -- 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: resolving _glgetstr...@4 by linking to _glGetString
> Not so much of an issue any more (still a bit curious about it, but). I
soon
> found that providing a '-lopengl32' link instead of
> '/cygdrive/c/Windows/System32/opengl32.dll' fixed the problem.
Linking to /cygdrive/c/windows/system32/whatever is "never" right.
It is not easy to explain this though.
In the "Unix model", the "headers and libraries" come with the operating system.
/usr/include, /lib, /usr/lib, etc.
In the "Windows model", they come separately with the compiler or a
"development kit".
The "Unix model" advantages:
system is "self describing"
smaller: no separate "import libraries", just the dynamic libraries
The "Windows model" advantages:
Sort of more amenable to cross builds. Including targeting an older or newer
OS release.
I say "sort of" because, like, adding additional headers and libraries doesn't
change the model.
In the "Unix model", any headers/libraries apart from "the OS" are sort of
following a different model,
where in the "Windows model", they are all following the same model.
This isn't the "Unix" or "Windows" model really, it is just how things tend to
be done on those systems.
If you look at Mac OS X development systems, they are closer to Windows.
If you have ever used "sysroot" with gcc, well, that is like Windows then.
Personally I prefer the Windows model.
And Cygwin follows it, because, well, again, the main difference is if the
operating system
contains the headers/libraries needed. Cygwin can be as Gnuy/Linuxy/Posixy as
it wants, but
the operating system doesn't contain the files it needs, so it includes them.
Now, there is something funny to this term "libraries".
You know, modern systems are heavily dynamically linked, and the information
needed
by the dynamic linker and the "static linker" is similar/same, in particular
for the "static linker"
to build an executable or library that references symbols dynamically.
The main information is just a list of function names.
Sometimes what library contains what function, depending on the system and
compiler/linker flags.
Thus it becomes reasonable seeming to point at the "running code" for
libraries, instead
of some separate libraries, sometimes called "stub libraries" or "import
libraries", etc.
(These "import libraries" basically just contain lists of function names, no
actual code;
older forms of them do contain a jmp per function, but that hardly counts.)
Now, then, what is the difference between the file -lopengl32 found, vs.
/cygdrive/c/windows/system32/opengl32.dll?
Well, Windows on x86 does have something uniquely slightly bad about it: There
are multiple calling conventions.
And the different calling conventions lead to a form of "name mangling", even
in C code.
There are generally three calling conventions.
Though some compilers let you declare custom ones, e.g. I believe gcc and
OpenWatcom.
As well the compiler can create custom calling conventions for "static"
functions. That is a different more general point and
true on many systems.
Anyway, the three usual Windows/x86 calling conventions are "stdcall", "cdecl",
"fastcall".
"cdecl" is usually the default.
Parameters passed on the stack, right to left, callER pops, function "Foo" is
"mangled" to "_Foo".
"stdcall" is heavily used.
Parameters passed on the stack, right to left, callEE pops, function "Foo" is
"mangled" to "_...@n"
where "N" is the decimal number of bytes of parameters, e.g. 0, 4, 8, 16, etc.
"fastcall" I don't know entirely, but roughly speaking, it passes the first 8
bytes of parameters in ecx, edx,
right to left, the rest on the stack, callEE pops, "Foo" becomes "_...@foo@N".
"cdecl" is "needed" for varargs i.e. printf, because caller pops.
"stdcall" is smaller/faster because callee pops.
Now, I said "stdcall" is heavily used.
Almost all public Windows functions (aka APIs) are stdcall.
So instead of generating a reference to " _glGetString", the compiler generates
a reference to " _glgetstr...@4".
However presumably because it looks nicer or maybe for consistency with the
other architectures, the exported
names are not "mangled" (or "decorated").
("other architectures": NT on MIPS, Alpha, PowerPC, IA64, AMD64, only one
calling convention each)
If you run link -dump -exports %windir%\system32\opengl32.dll, you'll see plain
"glGetString".
There is no clear indication in the .dll that glGetString takes 4 bytes of
parameters (maybe if you disassemble it...)
The file -lopengl32 found though, contains some stuff in it with both strings
"_glgetstr...@4" and "glGetString".
The first is what symbol the linker should resolve against, the second is what
it should stuck in the special data in the
file it is outputing.
Make sense?
(To repeat, I think distributing headers/libraries separate is good, but having
multiple calling conventions is clearly mixed/bad.)
- Jay
--
Problem reports: http://
RE: Cygwin Maximum Memory Documentation
On 64bit systems, /largeaddressaware gives 32bit processes 4GB of address space, and no need to boot with a special option (well, other than using a 64bit OS!). search for "largeaddressaware": http://blogs.msdn.com/oldnewthing/archive/2005/06/01/423817.aspx - Jay Cygwin Maximum Memory Documentation 162246 by: Rob Donovan --Forwarded Message Attachment-- Date: Tue, 27 Apr 2010 12:32:39 -0700 From: hikerman2005...@ To: cygwin@ Subject: Cygwin Maximum Memory Documentation -- 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: running MS link.exe under Cygwin sshd?
> From: reply-to-list-only...@cygwin.com > On 08/03/2009 12:11 AM, Jay K wrote: >> I found that Interix sshd and WinSSHD work ok here. >> So it is something specific to Cygwin. > Are you talking about password or public key authentication? If the > latter, Have you tried the LSA authentication package in Cygwin 1.7? I don't know. I'll try to deciper that. Sounds complicated. In the meantime, friend is using freesshd. Thanks Larry. - Jay -- 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: running MS link.exe under Cygwin sshd?
Friend also found freesshd works and will use that. So 3 out of 4 sshd work, Cygwin sshd is the only one that doesn't. - Jay [snip] -- 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: running MS link.exe under Cygwin sshd?
I found that Interix sshd and WinSSHD work ok here. So it is something specific to Cygwin. - Jay > From: jay.kr...@cornell.edu > To: cygwin@cygwin.com > Subject: running MS link.exe under Cygwin sshd? > Date: Sat, 1 Aug 2009 04:50:15 + > > > http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/eb49be0b-2a8c-4d55-8791-17e3cb1364c1 > > " > This issue is caused because cygwin does not implement a full login process. > It tries to impersonate, but it looks to me as if it does not make the > necessary call to LsaLogonUser. As a result, the wrong SID is in the token as > the primary user. According to filemon, the debug server calls into secur32, > which suggests that it is doing interpretive access control. It finds the > service's SID instead of the users SID in some slot in the token that it gets > via RPC, and then everything goes downhill from there.Why VS feels the need > to put the PDB access in a separate process under separate access rights is > very puzzling, but there it is. > " > > > Bug in Cygwin sshd? > > > - Jay > -- 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
running MS link.exe under Cygwin sshd?
http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/eb49be0b-2a8c-4d55-8791-17e3cb1364c1 " This issue is caused because cygwin does not implement a full login process. It tries to impersonate, but it looks to me as if it does not make the necessary call to LsaLogonUser. As a result, the wrong SID is in the token as the primary user. According to filemon, the debug server calls into secur32, which suggests that it is doing interpretive access control. It finds the service's SID instead of the users SID in some slot in the token that it gets via RPC, and then everything goes downhill from there.Why VS feels the need to put the PDB access in a separate process under separate access rights is very puzzling, but there it is. " Bug in Cygwin sshd? - Jay -- 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
