Re: Window flickering problem in XWin multiwindow mode
Replying to myself.. Hello, S.J. Luo wrote: SL on Apr 26, 2022: I have some EDA tools running on a Linux machine and display on my Windows PC using xorg-server-21.1.3 XWin multiwindow mode Sometimes the application window flickers forever for an unknown reason. The problem became more severe after my PC upgrade to Windows10. After re-compiling and debugging, I found a calling loop triggered. Knowing the root cause, I am now able to demonstrate the issue with a small test case as well as a patch that works for me. Both are attached below. Any one successfully duplicated the issue? I've reproduced it. That's a really annoying effect/issue you're seeing. I've been waiting for the Cygwin X maintainer to respond. I'm not familiar enough with X internals to know whether your patch is the most appropriate fix. I will try to build the object you're patching, with your patch, and make that available to you as a workaround. I'm assuming you haven't done that yourself just yet.. Give me a day or so to work it out. I may have misread your post. It now seems to me you've built an X server with your patch for your own use; you were just needing some acknowledgement from the Cygwin folks of the issue you reported. In any case, anybody else who runs into the flickering window issue and needs a workaround, you can pick up a patched X Window server (64-bit) that I've placed in a public location: http://maxrnd.com/~mark/cygwin/x86_64/XWin.exe . Cheers, ..mark -- 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: bash: cd: /cygdrive/w: Too many levels of symbolic links
On Fri, 29 Apr 2022 18:27:45 -0500 Wes Barris wrote: > On 4/29/2022 6:09 PM, Takashi Yano wrote: > > On Fri, 29 Apr 2022 14:21:01 -0500 > > Wes Barris wrote: > >> For the past couple of months the latest versions of cygwin produce this > >> error > >> when attempting to reference a network drive. There have been a couple of > >> other > >> threads reporting this and talk about patches. Is there a fix coming for > >> this > >> in the production version of cygwin? > >> > >> $ cd /cygdrive/w > >> bash: cd: /cygdrive/w: Too many levels of symbolic links > >> $ mount > >> C:/cygwin64/bin on /usr/bin type ntfs (binary,auto) > >> C:/cygwin64/lib on /usr/lib type ntfs (binary,auto) > >> C:/cygwin64 on / type ntfs (binary,auto) > >> C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user,noumount,auto) > >> D: on /cygdrive/d type ntfs (binary,noacl,posix=0,user,noumount,auto) > >> M: on /cygdrive/m type ntfs (binary,noacl,posix=0,user,noumount,auto) > >> P: on /cygdrive/p type ntfs (binary,noacl,posix=0,user,noumount,auto) > >> S: on /cygdrive/s type ntfs (binary,noacl,posix=0,user,noumount,auto) > >> V: on /cygdrive/v type ntfs (binary,noacl,posix=0,user,noumount,auto) > >> W: on /cygdrive/w type ntfs (binary,noacl,posix=0,user,noumount,auto) > > > > https://cygwin.com/pipermail/cygwin/2022-April/251332.html > > > > Thanks. Yes, that post describes what is happening to me. Is there a fix > coming for this? We are planning to release cygwin 3.3.5 in which the issue has been fixed soon after a few ongoing issues will be settled. -- Takashi Yano -- 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: Window flickering problem in XWin multiwindow mode
Hello, S.J. Luo wrote: SL on Apr 26, 2022: I have some EDA tools running on a Linux machine and display on my Windows PC using xorg-server-21.1.3 XWin multiwindow mode Sometimes the application window flickers forever for an unknown reason. The problem became more severe after my PC upgrade to Windows10. After re-compiling and debugging, I found a calling loop triggered. Knowing the root cause, I am now able to demonstrate the issue with a small test case as well as a patch that works for me. Both are attached below. Any one successfully duplicated the issue? I've reproduced it. That's a really annoying effect/issue you're seeing. I've been waiting for the Cygwin X maintainer to respond. I'm not familiar enough with X internals to know whether your patch is the most appropriate fix. I will try to build the object you're patching, with your patch, and make that available to you as a workaround. I'm assuming you haven't done that yourself just yet.. Give me a day or so to work it out. ..mark -- 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: Window flickering problem in XWin multiwindow mode
SL on Apr 26, 2022:
> I have some EDA tools running on a Linux machine and display on my Windows
> PC using xorg-server-21.1.3 XWin multiwindow mode
> Sometimes the application window flickers forever for an unknown reason.
> The problem became more severe after my PC upgrade to Windows10.
> After re-compiling and debugging, I found a calling loop triggered.
> Knowing the root cause, I am now able to demonstrate the issue with a small
> test case as well as a patch that works for me. Both are attached below.
Any one successfully duplicated the issue?
I minor revised the test case so it won't silently go exit on wrong DISPLAY
setting and added some comment. The running steps:
gcc -o flicker2 flicker2.c -lX11
/usr/bin/XWin.exe :11 -ac -multiwindow &
DISPLAY=:11 flicker2.exe
On running, you would see a window switching rapidly between max and normal
states and never stops.
The key of triggering the window flickering(or flashing) are these two lines:
SetWindowMax(display, win, _NET_WM_STATE_ADD);
SetWindowMax(display, win, _NET_WM_STATE_REMOVE);
where they just set the window to be maximized and go back to normal.
Removing either of the two, the test case would become normal.
I've tried this test case on 3PCs including Windows 7 and Windows 10
and in all cases the issue happens.
This issue literally occurs on my work that runs some proprietary Linux
EDA software. I wish this can be solved on next update.
SL
flicker2.c
===
#include
#include
#include
#include
#define _NET_WM_STATE_REMOVE0
#define _NET_WM_STATE_ADD 1
void SetWindowMax(Display *dpy, Window win, int state)
{
XEvent xev;
Atom wm_state = XInternAtom(dpy, "_NET_WM_STATE", False);
Atom max_horz = XInternAtom(dpy, "_NET_WM_STATE_MAXIMIZED_HORZ", False);
Atom max_vert = XInternAtom(dpy, "_NET_WM_STATE_MAXIMIZED_VERT", False);
memset(, 0, sizeof(xev));
xev.type = ClientMessage;
xev.xclient.window = win;
xev.xclient.message_type = wm_state;
xev.xclient.format = 32;
xev.xclient.data.l[0] = state;
xev.xclient.data.l[1] = max_horz;
xev.xclient.data.l[2] = max_vert;
XSendEvent(dpy, DefaultRootWindow(dpy), False,
SubstructureNotifyMask, );
}
int main(void) {
Display *display;
Window win;
XEvent xev;
int screen;
if (!(display = XOpenDisplay(NULL))) {
printf("Cannot open display. Please check DISPLAY environmet setting.\n");
exit(1);
}
screen = DefaultScreen(display);
win = XCreateSimpleWindow(display, RootWindow(display, screen),
10, 10, 100, 100, 0,
BlackPixel(display, screen), WhitePixel(display, screen));
XMapWindow(display, win);
// Uncomment either of the following two lines
// and window would not go flashing
SetWindowMax(display, win, _NET_WM_STATE_ADD);
SetWindowMax(display, win, _NET_WM_STATE_REMOVE);
while(1) {
XNextEvent(display, );
}
// It is supposed never get here
XCloseDisplay(display);
return 0;
}
===
--
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: cygdll 3.3.4 breaks cygpath.exe. mistyped commands result in fork bomb
> Can you try the suggestions I made in my reply >https://cygwin.com/pipermail/cygwin/2022-February/250790.html ? sorry, no. Even though I have Admin I am unable to override this. Please note that all previous versions of cygwin1.dll (<3.3.3) are not interfered with. Though if this is indeed Sentinel, it does seem to *sporadically* kill threads launched under strace regardless of cygwin DLL version all the way back to 3.1.7. -- 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: bash: cd: /cygdrive/w: Too many levels of symbolic links
On 4/29/2022 6:09 PM, Takashi Yano wrote: On Fri, 29 Apr 2022 14:21:01 -0500 Wes Barris wrote: For the past couple of months the latest versions of cygwin produce this error when attempting to reference a network drive. There have been a couple of other threads reporting this and talk about patches. Is there a fix coming for this in the production version of cygwin? $ cd /cygdrive/w bash: cd: /cygdrive/w: Too many levels of symbolic links $ mount C:/cygwin64/bin on /usr/bin type ntfs (binary,auto) C:/cygwin64/lib on /usr/lib type ntfs (binary,auto) C:/cygwin64 on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,noacl,posix=0,user,noumount,auto) M: on /cygdrive/m type ntfs (binary,noacl,posix=0,user,noumount,auto) P: on /cygdrive/p type ntfs (binary,noacl,posix=0,user,noumount,auto) S: on /cygdrive/s type ntfs (binary,noacl,posix=0,user,noumount,auto) V: on /cygdrive/v type ntfs (binary,noacl,posix=0,user,noumount,auto) W: on /cygdrive/w type ntfs (binary,noacl,posix=0,user,noumount,auto) https://cygwin.com/pipermail/cygwin/2022-April/251332.html Thanks. Yes, that post describes what is happening to me. Is there a fix coming for this? -- Wes Barris -- This email has been checked for viruses by AVG. https://www.avg.com -- 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: bash: cd: /cygdrive/w: Too many levels of symbolic links
On Fri, 29 Apr 2022 14:21:01 -0500 Wes Barris wrote: > For the past couple of months the latest versions of cygwin produce this > error > when attempting to reference a network drive. There have been a couple of > other > threads reporting this and talk about patches. Is there a fix coming for > this > in the production version of cygwin? > > $ cd /cygdrive/w > bash: cd: /cygdrive/w: Too many levels of symbolic links > $ mount > C:/cygwin64/bin on /usr/bin type ntfs (binary,auto) > C:/cygwin64/lib on /usr/lib type ntfs (binary,auto) > C:/cygwin64 on / type ntfs (binary,auto) > C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user,noumount,auto) > D: on /cygdrive/d type ntfs (binary,noacl,posix=0,user,noumount,auto) > M: on /cygdrive/m type ntfs (binary,noacl,posix=0,user,noumount,auto) > P: on /cygdrive/p type ntfs (binary,noacl,posix=0,user,noumount,auto) > S: on /cygdrive/s type ntfs (binary,noacl,posix=0,user,noumount,auto) > V: on /cygdrive/v type ntfs (binary,noacl,posix=0,user,noumount,auto) > W: on /cygdrive/w type ntfs (binary,noacl,posix=0,user,noumount,auto) https://cygwin.com/pipermail/cygwin/2022-April/251332.html -- Takashi Yano -- 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: cygdll 3.3.4 breaks cygpath.exe. mistyped commands result in fork bomb
On 4/29/2022 2:25 PM, matthew patton via Cygwin wrote: --- Process 25852 loaded C:\Program Files\SentinelOne\Sentinel Agent 21.7.4.1043\InProcessClient64.dll at 7fff9d48 This looks like the problem that was reported here: https://cygwin.com/pipermail/cygwin/2022-February/250782.html Can you try the suggestions I made in my reply https://cygwin.com/pipermail/cygwin/2022-February/250790.html ? Ken -- 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
[ANNOUNCEMENT] Updated: neomutt-20220429-1
Version 20220429-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20220429. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
Updated: neomutt-20220429-1
Version 20220429-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20220429. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico
bash: cd: /cygdrive/w: Too many levels of symbolic links
For the past couple of months the latest versions of cygwin produce this error when attempting to reference a network drive. There have been a couple of other threads reporting this and talk about patches. Is there a fix coming for this in the production version of cygwin? $ cd /cygdrive/w bash: cd: /cygdrive/w: Too many levels of symbolic links $ mount C:/cygwin64/bin on /usr/bin type ntfs (binary,auto) C:/cygwin64/lib on /usr/lib type ntfs (binary,auto) C:/cygwin64 on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,noacl,posix=0,user,noumount,auto) M: on /cygdrive/m type ntfs (binary,noacl,posix=0,user,noumount,auto) P: on /cygdrive/p type ntfs (binary,noacl,posix=0,user,noumount,auto) S: on /cygdrive/s type ntfs (binary,noacl,posix=0,user,noumount,auto) V: on /cygdrive/v type ntfs (binary,noacl,posix=0,user,noumount,auto) W: on /cygdrive/w type ntfs (binary,noacl,posix=0,user,noumount,auto) -- Wes Barris -- This email has been checked for viruses by AVG. https://www.avg.com -- 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: cygdll 3.3.4 breaks cygpath.exe. mistyped commands result in fork bomb
I've identified the proximate cause. env CYGWIN_NOWINPATH= With this variable set at all (0 or 1, doesn't matter) typing ''l' (that's el) spawns several hundred bash.exe and fork bombs. From a stable prompt, typing 'exit' spawns 80+ bash.exe and I have to use the X button to kill the window and the run-away bash.exe fork bomb. With CYGWIN DLL v3.2.0 or earlier hitting Ctrl-C shuts down the fork bomb at the command-line - the processes self-reap. With v3.3.x family Ctrl-C gives me my command-line back but requires 'pkill -9 bash.exe' over and over till the rogue process count is reigned in. If I unset CYGWIN_NOWINPATH I obviously pollute my environment with DOS programs but typing 'l' (el) returns immediately with: 'l' is not recognized as an internal or external command,operable program or batch file. Did someone stupidly delegate the search for executables to blindly call CMD.exe and since with NOWINPATH set CMD.exe can't be found so it just fork bombs?On Friday, April 29, 2022, 02:25:38 PM EDT, matthew patton via Cygwin wrote: --- Process 25852 created--- Process 25852 loaded C:\Windows\System32\ntdll.dll at 7fffa01b--- Process 25852 loaded C:\Windows\System32\kernel32.dll at 7fff9eef--- Process 25852 loaded C:\Windows\System32\KernelBase.dll at 7fff9db0--- Process 25852 loaded C:\Program Files\SentinelOne\Sentinel Agent 21.7.4.1043\InProcessClient64.dll at 7fff9d48--- Process 25852 loaded C:\Windows\System32\advapi32.dll at 7fff9f8a--- Process 25852 loaded C:\Windows\System32\msvcrt.dll at 7fffa00d--- Process 25852 thread 20692 created--- Process 25852 loaded C:\Windows\System32\sechost.dll at 7fff9edc--- Process 25852 loaded C:\Windows\System32\rpcrt4.dll at 7fff9ff3--- Process 25852 thread 25940 created--- Process 25852 thread 22408 created--- Process 25852 loaded C:\Windows\System32\shell32.dll at 7fff9e21--- Process 25852 loaded C:\Windows\System32\msvcp_win.dll at 7fff9de6--- Process 25852 loaded C:\cyg64\bin\cygwin1.dll at 00018004--- Process 25852 loaded C:\Windows\System32\ucrtbase.dll at 7fff9d98--- Process 25852 loaded C:\Windows\System32\user32.dll at 7fff9e9c--- Process 25852 loaded C:\Windows\System32\win32u.dll at 7fff9e08--- Process 25852 loaded C:\Windows\System32\gdi32.dll at 7fff9ee6--- Process 25852 loaded C:\Windows\System32\gdi32full.dll at 7fff9df7--- Process 25852 loaded C:\Windows\System32\userenv.dll at 7fff9d79--- Process 25852 loaded C:\Windows\System32\imm32.dll at 7fff9eca 327 329 [main] cygpath (25852) Program name: C:\cyg64\bin\cygpath.exe (windows pid 25852) 248 577 [main] cygpath (25852) OS version: Windows NT-10.0 288 865 [main] cygpath (25852) **--- Process 25852 loaded C:\Windows\System32\cryptbase.dll at 7fff9cef--- Process 25852 loaded C:\Windows\System32\bcryptprimitives.dll at 7fff9ddd 5888 6753 [main] cygpath (25852) sigprocmask: 0 = sigprocmask (0, 0x0, 0x180321570) 735 7488 [main] cygpath (25852) open_shared: name shared.5, n 5, shared 0x18003 (wanted 0x18003), h 0x184, *m 6 210 7698 [main] cygpath (25852) user_heap_info::init: heap base 0x8, heap top 0x8, heap size 0x2000 (536870912) 175 7873 [main] cygpath (25852) open_shared: name S-1-5-21-1343024091-839522115-1708537768-180174.1, n 1, shared 0x18002 (wanted 0x18002), h 0x180, *m 6 160 8033 [main] cygpath (25852) user_info::create: opening user shared for 'S-1-5-21-1343024091-839522115-1708537768-180174' at 0x18002 157 8190 [main] cygpath (25852) user_info::create: user shared version AB1FCCE8 112 8302 [main] cygpath (25852) fhandler_pipe::create: name \\.\pipe\cygwin-d9238e605d902b75-25852-sigwait, size 11440, mode PIPE_TYPE_MESSAGE 230 8532 [main] cygpath (25852) fhandler_pipe::create: pipe read handle 0x98 160 8692 [main] cygpath (25852) fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-d9238e605d902b75-25852-sigwait 145 8837 [main] cygpath (25852) fhandler_pipe::create: pipe write handle 0x198 142 8979 [main] cygpath (25852) dll_crt0_0: finished dll_crt0_0 initialization--- Process 25852 thread 17084 created--- Process 25852, exception c005 at 0001801390e4--- Process 25852, exception 8001 at 7fff9d4c9767--- Process 25852 thread 25940 exited with status 0x8001--- Process 25852 thread 22408 exited with status 0x8001--- Process 25852 thread 17084 exited with status 0x8001--- Process 25852 thread 17688 exited with status 0x8001--- Process 25852 exited with status 0x8001 hmm so downgraded to 3.3.3 again and the program runs. But if I use strace the process gets half-killed. Trying to exit from '--help' Ctrl-C results in repeated lines like so and I have to force-close the window --- Process
Re: alternatives package dose not install /sbin executables
Am 29.04.2022 um 18:40 schrieb David Rogers via Cygwin: I successfully installed: alternatives1.3.30c-10 OK According to the alternatives package file list I should have the following executables installed: alternatives.exe and update-alternatives.exe, Yes. But I checked my /sbin directory not in that directory. If you examine the package listing once more, you'll find they're actually supposed to be in /usr/sbin. -- 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: cygdll 3.3.4 breaks cygpath.exe. mistyped commands result in fork bomb
--- Process 25852 created--- Process 25852 loaded C:\Windows\System32\ntdll.dll at 7fffa01b--- Process 25852 loaded C:\Windows\System32\kernel32.dll at 7fff9eef--- Process 25852 loaded C:\Windows\System32\KernelBase.dll at 7fff9db0--- Process 25852 loaded C:\Program Files\SentinelOne\Sentinel Agent 21.7.4.1043\InProcessClient64.dll at 7fff9d48--- Process 25852 loaded C:\Windows\System32\advapi32.dll at 7fff9f8a--- Process 25852 loaded C:\Windows\System32\msvcrt.dll at 7fffa00d--- Process 25852 thread 20692 created--- Process 25852 loaded C:\Windows\System32\sechost.dll at 7fff9edc--- Process 25852 loaded C:\Windows\System32\rpcrt4.dll at 7fff9ff3--- Process 25852 thread 25940 created--- Process 25852 thread 22408 created--- Process 25852 loaded C:\Windows\System32\shell32.dll at 7fff9e21--- Process 25852 loaded C:\Windows\System32\msvcp_win.dll at 7fff9de6--- Process 25852 loaded C:\cyg64\bin\cygwin1.dll at 00018004--- Process 25852 loaded C:\Windows\System32\ucrtbase.dll at 7fff9d98--- Process 25852 loaded C:\Windows\System32\user32.dll at 7fff9e9c--- Process 25852 loaded C:\Windows\System32\win32u.dll at 7fff9e08--- Process 25852 loaded C:\Windows\System32\gdi32.dll at 7fff9ee6--- Process 25852 loaded C:\Windows\System32\gdi32full.dll at 7fff9df7--- Process 25852 loaded C:\Windows\System32\userenv.dll at 7fff9d79--- Process 25852 loaded C:\Windows\System32\imm32.dll at 7fff9eca 327 329 [main] cygpath (25852) Program name: C:\cyg64\bin\cygpath.exe (windows pid 25852) 248 577 [main] cygpath (25852) OS version: Windows NT-10.0 288 865 [main] cygpath (25852) **--- Process 25852 loaded C:\Windows\System32\cryptbase.dll at 7fff9cef--- Process 25852 loaded C:\Windows\System32\bcryptprimitives.dll at 7fff9ddd 5888 6753 [main] cygpath (25852) sigprocmask: 0 = sigprocmask (0, 0x0, 0x180321570) 735 7488 [main] cygpath (25852) open_shared: name shared.5, n 5, shared 0x18003 (wanted 0x18003), h 0x184, *m 6 210 7698 [main] cygpath (25852) user_heap_info::init: heap base 0x8, heap top 0x8, heap size 0x2000 (536870912) 175 7873 [main] cygpath (25852) open_shared: name S-1-5-21-1343024091-839522115-1708537768-180174.1, n 1, shared 0x18002 (wanted 0x18002), h 0x180, *m 6 160 8033 [main] cygpath (25852) user_info::create: opening user shared for 'S-1-5-21-1343024091-839522115-1708537768-180174' at 0x18002 157 8190 [main] cygpath (25852) user_info::create: user shared version AB1FCCE8 112 8302 [main] cygpath (25852) fhandler_pipe::create: name \\.\pipe\cygwin-d9238e605d902b75-25852-sigwait, size 11440, mode PIPE_TYPE_MESSAGE 230 8532 [main] cygpath (25852) fhandler_pipe::create: pipe read handle 0x98 160 8692 [main] cygpath (25852) fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-d9238e605d902b75-25852-sigwait 145 8837 [main] cygpath (25852) fhandler_pipe::create: pipe write handle 0x198 142 8979 [main] cygpath (25852) dll_crt0_0: finished dll_crt0_0 initialization--- Process 25852 thread 17084 created--- Process 25852, exception c005 at 0001801390e4--- Process 25852, exception 8001 at 7fff9d4c9767--- Process 25852 thread 25940 exited with status 0x8001--- Process 25852 thread 22408 exited with status 0x8001--- Process 25852 thread 17084 exited with status 0x8001--- Process 25852 thread 17688 exited with status 0x8001--- Process 25852 exited with status 0x8001 hmm so downgraded to 3.3.3 again and the program runs. But if I use strace the process gets half-killed. Trying to exit from '--help' Ctrl-C results in repeated lines like so and I have to force-close the window --- Process 14340, exception c005 at 00018013875c--- Process 14340 thread 28092 created--- Process 14340 thread 22872 created--- Process 14340, exception 40010005 at 7fff9dbbd67312655695 12666948 [] cygpath (14340) _cygtls::remove: wait 0--- Process 14340 thread 22872 exited with status 0x0--- Process 14340 thread 19264 created--- Process 14340 thread 22068 created--- Process 14340, exception 40010005 at 7fff9dbbd673--- Process 14340, exception 40010005 at 7fff9dbbd673 All because I decided to upgrade my installation which had been perfectly fine for well over a year... On Friday, April 29, 2022, 05:04:23 AM EDT, Takashi Yano wrote: On Fri, 29 Apr 2022 00:22:09 + (UTC) matthew patton wrote: > I had to revert to 3.3.3-1 to restore functionality.with 3.3.4 invoking > cygpath would cause an Access Violation Exception (0x05) and kill the thread > so that I couldn't even do a 'cygpath --help' > > All of a sudden I also am experiencing fork bombs if I type an invalid > command. eg. type 'l' instead of 'ls' and ENTER, it
RE: Link of ONC RPC client fails with: undefined references
Thank you.
This fixed it:
- $(CC) $^ $(LD_LIBS) -o $@
+ $(CC) $(LD_LIBS) -o $@ $^
Now I'm trying to understand why rpcbind fails at
/usr/src/debug/rpcbind-1.2.5-1/src/rpcbind.c:287, even when run from an
elevated command prompt:
268 if((p = getpwnam(id)) == NULL) {
269 syslog(LOG_ERR, "cannot get uid of '%s': %m", id);
270 exit(1);
271 }
...
285 if (setuid(p->pw_uid) == -1) {
286 syslog(LOG_ERR, "setuid to '%s' (%d) failed:
%m", id, p->pw_uid);
287 exit(1);
288 }
I do find this:
Under "Switching the user context", https://cygwin.com/cygwin-ug-net/ntsec.html
says
> Windows does not support the concept of these calls in a simple fashion.
> Switching the user context in Windows is generally a tricky process with lots
> of "behind the scenes" magic involved.
>
> \[H\]ow can this \[information\] be used to implement set(e)uid? Well, it
> requires modification of the calling application.
Based on skim of the this source, that implies that this rpcbind would never
work which doesn't make sense.
> -Original Message-
> From: Jon Turney
> Sent: 29 April 2022 05:29
> To: Voris, Ben ; The Cygwin Mailing List
>
> Subject: Re: Link of ONC RPC client fails with: undefined references
>
> On 29/04/2022 04:06, Voris, Ben wrote:
> > I have simple ONC RPC client and server that build on Ubuntu with rpcgen
> "(Ubuntu GLIBC 2.31-0ubuntu9.7) 2.31" (under "5.10.102.1-microsoft-standard-
> WSL2") but fails to build on Cygwin ("3.3.4(0.341/5/3) 2022-01-31 19:35 x86_64
> Cygwin") with rpcgen "(rpcsvc-proto) 1.4".
> >
> > Naively, it appears that Ubuntu has a much newer version (2.31) than Cygwin
> (1.4). Is this the problem?
> >
> > gzip'ed cygcheck output and the test program and makefile are attached.
> >
> > Output of "make all"
> [...]
> > gcc -ltirpc -o objs/date_client objs/date_client.o objs/date_clnt.o
> > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
> objs/date_client.o: in function `date_prog_1':
> > /home/BVoris/git/ONC-rpc-test/src/date_client.c:15: undefined reference to
> `clnt_create'
> > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
> /home/BVoris/git/ONC-rpc-test/src/date_client.c:17: undefined reference to
> `clnt_pcreateerror'
> > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
> /home/BVoris/git/ONC-rpc-test/src/date_client.c:33: undefined reference to
> `clnt_perror'
> > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
> objs/date_clnt.o:date_clnt.c:(.rdata$.refptr.xdr_wrapstring[.refptr.xdr_wrapstr
> ing]+0x0): undefined reference to `xdr_wrapstring'
>
> I suspect the problem here is due to the position of '-ltirpc' in the
> compiler command line. Moving it to after the .o files might help.
> See
> INVALID URI REMOVED
> _;Iw!!NpxR!mh4II02xebe-
> AOaVrVnhqLMZ184wpNJtizkEmBv2uzw49eZ11dNZZClae3F00QGiI4IjKo7KYcBeP0qGGZVCzgU$
> for details why.
--
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
alternatives package dose not install /sbin executables
Due to security I had to remove some lines from cygcheck report I successfully installed: alternatives1.3.30c-10 OK According to the alternatives package file list I should have the following executables installed: alternatives.exe and update-alternatives.exe, see sbin.log I checked my /sbin directory after installation and the two files for alternatives were not installed: see attached file, cygcheck.log sbin.log Description: sbin.log cygcheck.log Description: cygcheck.log -- 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: [Attn: mercurial maintainer] hg fails with python3.9
On 2022-04-29 12:23, Jon Turney wrote: > > >libdir = '../lib/python3.8/site-packages' > > > > > > This causes hg to fail as follows if /usr/bin/python3 points to python3.9: > > > >ERROR: package 'mercurial' version '5.7-3' is most recent non-test > > version, but version '6.0-1' is curr > > This error is trying to tell you "version 6.0-1 exists, so the version you > are uploading won't be installed for anyone who already has that higher > version number installed, so maybe this isn't what you want to do". > > mercurial version 6.0-1 does exist, for x86_64 only, dated 2021-11-25. My mistake. I had the development environment in wrong server, so only 5.7 was in there and I forgot to check the latest in Cygwin. 6.1.1-1 uploaded Thanks, Jari -- 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: Home directory on network drive not accessible in 3.3.4
On Fri, 29 Apr 2022 13:59:59 +0200 Thomas Wolff wrote: > I upgraded 3.3.3 → 3.3.4 in a lab environment, where my home directory > is H:\ or /cygdrive/h > > Starting cygwin (cmd/bash or mintty) with some tools from gnuutils (like > ls) in the path gives me this message: > > mkdir: cannot create directory ‘/cygdrive/h’: File exists > /cygdrive/h could not be created. > Setting HOME to /tmp. > > After clearing PATH, then running bash or mintty: > bash: /cygdrive/h/.bashrc: Too many levels of symbolic links > > $ cd /cygdrive/h > -bash: cd: /cygdrive/h: Too many levels of symbolic links > > $ /bin/ls -l /cygdrive > /bin/ls: /cygdrive/h: Too many levels of symbolic links > /bin/ls: /cygdrive/l: Too many levels of symbolic links > total 48 > d---r-x---+ 1 NT SERVICE+TrustedInstaller NT SERVICE+TrustedInstaller 0 > Apr 27 11:01 c > drwx---rwx+ 1 SYSTEM SYSTEM 0 Mar 23 15:41 d > drwxrwx--- 1 Administratoren Domänen-Admins 0 Nov 26 11:40 h > drwxrwxr-x 1 Administratoren Domänen-Admins 0 Dec 17 18:53 l > > $ /bin/mount > //141.64.144.100/Labormaterial/TGI/cygwin64/bin on /usr/bin type ntfs > (binary,auto) > //141.64.144.100/Labormaterial/TGI/cygwin64/lib on /usr/lib type ntfs > (binary,auto) > //141.64.144.100/Labormaterial/TGI/cygwin64 on / type ntfs (binary,auto) > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) > D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) > H: on /cygdrive/h type ntfs (binary,posix=0,user,noumount,auto) > L: on /cygdrive/l type ntfs (binary,posix=0,user,noumount,auto) > > Reverting to cygwin 3.3.3 solves the issue. Maybe related to the other > 3.3.4 problem reported today? This seems to be the issue which was already fixed in git head. https://cygwin.com/pipermail/cygwin-patches/2022q1/011729.html -- Takashi Yano -- 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
Home directory on network drive not accessible in 3.3.4
I upgraded 3.3.3 → 3.3.4 in a lab environment, where my home directory is H:\ or /cygdrive/h Starting cygwin (cmd/bash or mintty) with some tools from gnuutils (like ls) in the path gives me this message: mkdir: cannot create directory ‘/cygdrive/h’: File exists /cygdrive/h could not be created. Setting HOME to /tmp. After clearing PATH, then running bash or mintty: bash: /cygdrive/h/.bashrc: Too many levels of symbolic links $ cd /cygdrive/h -bash: cd: /cygdrive/h: Too many levels of symbolic links $ /bin/ls -l /cygdrive /bin/ls: /cygdrive/h: Too many levels of symbolic links /bin/ls: /cygdrive/l: Too many levels of symbolic links total 48 d---r-x---+ 1 NT SERVICE+TrustedInstaller NT SERVICE+TrustedInstaller 0 Apr 27 11:01 c drwx---rwx+ 1 SYSTEM SYSTEM 0 Mar 23 15:41 d drwxrwx--- 1 Administratoren Domänen-Admins 0 Nov 26 11:40 h drwxrwxr-x 1 Administratoren Domänen-Admins 0 Dec 17 18:53 l $ /bin/mount //141.64.144.100/Labormaterial/TGI/cygwin64/bin on /usr/bin type ntfs (binary,auto) //141.64.144.100/Labormaterial/TGI/cygwin64/lib on /usr/lib type ntfs (binary,auto) //141.64.144.100/Labormaterial/TGI/cygwin64 on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) H: on /cygdrive/h type ntfs (binary,posix=0,user,noumount,auto) L: on /cygdrive/l type ntfs (binary,posix=0,user,noumount,auto) Reverting to cygwin 3.3.3 solves the issue. Maybe related to the other 3.3.4 problem reported today? Kind regards, Thomas -- 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: `locale -s` shows incorrect info on systems where the language is changed after the OOBE
Am 29/04/2022 um 12:16 schrieb Gennaro Prota: Hi, the locale utility currently gets the system default UI locale (-s option) via GetSystemDefaultUILanguage(). This is a problem on systems where the default UI language is changed after the Windows Out of Box Experience (OOBE), because that function will happily ignore the fact (see < https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getsystemdefaultuilanguage ). FWIW, this is not just theoretical: on my work PC, which was set to Italian during the first setup (not by me), and is now set to US English, the locale utility shows: $ locale -s it_IT Please check: was the setting really changed for the whole system (i.e. also for other users) or only for your user account? Is the change reflected by locale -u? -- 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: Link of ONC RPC client fails with: undefined references
On 29/04/2022 04:06, Voris, Ben wrote:
I have simple ONC RPC client and server that build on Ubuntu with rpcgen "(Ubuntu GLIBC 2.31-0ubuntu9.7)
2.31" (under "5.10.102.1-microsoft-standard-WSL2") but fails to build on Cygwin ("3.3.4(0.341/5/3)
2022-01-31 19:35 x86_64 Cygwin") with rpcgen "(rpcsvc-proto) 1.4".
Naively, it appears that Ubuntu has a much newer version (2.31) than Cygwin
(1.4). Is this the problem?
gzip'ed cygcheck output and the test program and makefile are attached.
Output of "make all"
[...]
gcc -ltirpc -o objs/date_client objs/date_client.o objs/date_clnt.o
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
objs/date_client.o: in function `date_prog_1':
/home/BVoris/git/ONC-rpc-test/src/date_client.c:15: undefined reference to
`clnt_create'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
/home/BVoris/git/ONC-rpc-test/src/date_client.c:17: undefined reference to
`clnt_pcreateerror'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
/home/BVoris/git/ONC-rpc-test/src/date_client.c:33: undefined reference to
`clnt_perror'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
objs/date_clnt.o:date_clnt.c:(.rdata$.refptr.xdr_wrapstring[.refptr.xdr_wrapstring]+0x0):
undefined reference to `xdr_wrapstring'
I suspect the problem here is due to the position of '-ltirpc' in the
compiler command line. Moving it to after the .o files might help.
See https://cygwin.com/faq.html#faq.programming.linker for details why.
--
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
`locale -s` shows incorrect info on systems where the language is changed after the OOBE
Hi, the locale utility currently gets the system default UI locale (-s option) via GetSystemDefaultUILanguage(). This is a problem on systems where the default UI language is changed after the Windows Out of Box Experience (OOBE), because that function will happily ignore the fact (see < https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getsystemdefaultuilanguage >). FWIW, this is not just theoretical: on my work PC, which was set to Italian during the first setup (not by me), and is now set to US English, the locale utility shows: $ locale -s it_IT -- Gennaro -- 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: [Attn: mercurial maintainer] hg fails with python3.9
On 2022-04-28 10:27, Ken Brown wrote: > /usr/bin/hg specifies /usr/bin/python3 in its shebang, but further down it has > > libdir = '../lib/python3.8/site-packages' > > This causes hg to fail as follows if /usr/bin/python3 points to python3.9: > > $ hg > Traceback (most recent call last): > File "/usr/lib/python3.8/site-packages/mercurial/policy.py", line 69, in While uploading fix, I got this: ERROR: package 'mercurial' version '5.7-3' is most recent non-test version, but version '6.0-1' is curr: Jari -- 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: GNU make losing jobserver tokens
On Thu, 28 Apr 2022 17:32:22 +0200
Corinna Vinschen wrote:
> On Apr 29 00:01, Takashi Yano wrote:
> > On Thu, 28 Apr 2022 16:09:24 +0200
> > Corinna Vinschen wrote:
> > > On Apr 28 09:42, Ken Brown wrote:
> > > > On 4/27/2022 10:13 AM, Takashi Yano wrote:
> > > > > On Fri, 1 Apr 2022 17:45:51 +0900
> > > > > Takashi Yano wrote:
> > > > > > [...]
> > > > > > diff --git a/winsup/cygwin/sigproc.cc b/winsup/cygwin/sigproc.cc
> > > > > > index 62df96652..3824af199 100644
> > > > > > --- a/winsup/cygwin/sigproc.cc
> > > > > > +++ b/winsup/cygwin/sigproc.cc
> > > > > > @@ -1325,6 +1325,10 @@ wait_sig (VOID *)
> > > > > > _sig_tls = &_my_tls;
> > > > > > bool sig_held = false;
> > > > > > + /* Wait for _main_tls initialization. */
> > > > > > + while (!cygwin_finished_initializing)
> > > > > > +Sleep (10);
> > > > > > +
> > > > > > sigproc_printf ("entering ReadFile loop, my_readsig %p,
> > > > > > my_sendsig %p",
> > > > > > my_readsig, my_sendsig);
> > > > > >
> > > > > > I guess _main_tls may not be initialized correctly until
> > > > > > cygwin_finished_initializing is set.
> > > > > >
> > > > > > Any comments would be appreciated.
> > > >
> > > > This seems reasonable to me.
> >
> > Thanks Ken and Corinna.
> >
> > > Missed that, sorry. I agree this seems reasonable, but wouldn't it be
> > > cleaner if we *start* wait_sig only after cygwin_finished_initializing
> > > is set to true?
> >
> > I also thought so, however, there is a comment in dcrt0.cc
> > as follows. So, there seems to be some reason to start
> > wait_sig before cygwin_finished_initialization.
> >
> > /* Initialize signal processing here, early, in the hopes that the
> > creation
> > of a thread early in the process will cause more predictability in
> > memory
> > layout for the main thread. */
> > if (!dynamically_loaded)
> > sigproc_init ();
>
> This is a 32-bit only problem. The 64 bit address space layout is as
> predictable as can be. Maybe the above fix should go into 3.3 and for
> 3.4 we try differently?
I tried to move sigproc_init() call from dll_crt0_0() to
fork::child() for 64bit cygwin, however, that causes hang
at cygwin startup.
Am I missing somehting?
--
Takashi Yano
--
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: cygdll 3.3.4 breaks cygpath.exe. mistyped commands result in fork bomb
On Fri, 29 Apr 2022 00:22:09 + (UTC) matthew patton wrote: > I had to revert to 3.3.3-1 to restore functionality.with 3.3.4 invoking > cygpath would cause an Access Violation Exception (0x05) and kill the thread > so that I couldn't even do a 'cygpath --help' > > All of a sudden I also am experiencing fork bombs if I type an invalid > command. eg. type 'l' instead of 'ls' and ENTER, it spawns hundreds of > 'bash.exe' processes. A half dozen 'pkill -9 bash.exe' heads off calamity. That does not happen to me. -- Takashi Yano -- 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
