Re: Uploading packages built against Perl 5.2.2 [
Adam Dinwoodie writes: Is there a consensus on the way to upload files ready for Perl 5.22 to be made available? The Git packages are ready to go, but I'm not sure if I should be uploading them without a !ready file, or as a test release. Unfortunately, none of the folks with full access to sourceware have said if my idea with the !perl cookie was going to fly, so it seems like we'll have to coordinate among ourselves. I have been uploading my packages without the !ready file for now. Or is the idea just that we're going to try to coordinate the many maintainers worldwide to all release at the same time on Friday? As that'll mean it doesn't matter that there's no consensus, it just seems like it'll also be inordinately painful, too. One more thing that we'll have to solve one way or the other. I still hope that one maintainer with full sourceware access will be able to post the !ready cookies all at the same time. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [ANNOUNCEMENT] Update: mintty 2.1.2
Hi Thomas,
Let me rephrase/summarize my findings:
Executing 'mintty -D' (i.e. v212)
from a shortcut to bash (i.e. Cygwin console),
will fork itself, where the child will turn itself into a session leader, as
desired.
i.e. the following code will be executed:
#if 1 // Thomas
if (daemonize !isatty(0)) { // daemonize == true, !isatty(0) == true
if (fork() 0) exit(0);
setsid(); // executed by child
}
#endif
1. if 'Windows Basic' has been selected (Personalization), the child will
crash.
2. if 'Windows 7' has been selected (Personalization), the child will NOT
crash,
... and, eventually, fork itself, where the grandchild will replace
itself
by bash in the end.
Hi Thomas,
I _may_ have found the cause of the problem ... (but all bets are off!).
main() in winmain.c starts as follows:
int
main(int argc, char *argv[])
{
main_argv = argv;
main_argc = argc;
// Henri: too early?
#if 0
load_dwm_funcs();
#endif
load_dwm_funcs() apparently loads a library, as follows:
load_dwm_funcs
load_sys_library(dwmapi.dll)
LoadLibrary ...
Will the library still be loaded in the child, I asked myself ...
As an experiment, I moved the call to load_dwm_funcs() after fork/setsid.
... fork()
... setsid()
// child continues ...
// Henri: will dwmapi.dll still be loaded after the fork() call ?
#if 1
load_dwm_funcs();
#endif
Still more testing is needed ... but I _may_ have found why mintty -D crashes.
But
I cannot explain why the crash does not occur when eye candy has been enabled.
Henri
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Update: mintty 2.1.2
Hi Thomas,
Moving load_dwm_funcs() did the trick ...
Tested on 32-bits and 64-bits, W7
See appendix (winmain.c)
Henri// win.c (part of mintty)
// Copyright 2008-13 Andy Koppe
// Based on code from PuTTY-0.60 by Simon Tatham and team.
// Licensed under the terms of the GNU General Public License v3 or later.
#include winpriv.h
#include term.h
#include appinfo.h
#include child.h
#include charset.h
#include locale.h
#include getopt.h
#include pwd.h
#include shellapi.h
#include sys/cygwin.h
HINSTANCE inst;
HWND wnd;
HIMC imc;
bool win_is_full_screen;
static char **main_argv;
static int main_argc;
static ATOM class_atom;
static int extra_width, extra_height;
static bool fullscr_on_max;
static bool resizing;
static bool title_settable = true;
static bool daemonize = false;
static string border_style = 0;
static HBITMAP caretbm;
#if WINVER 0x600
typedef struct {
int cxLeftWidth;
int cxRightWidth;
int cyTopHeight;
int cyBottomHeight;
} MARGINS;
#endif
static HRESULT (WINAPI *pDwmIsCompositionEnabled)(BOOL *);
static HRESULT (WINAPI *pDwmExtendFrameIntoClientArea)(HWND, const MARGINS *);
// Helper for loading a system library. Using LoadLibrary() directly is insecure
// because Windows might be searching the current working directory first.
static HMODULE
load_sys_library(string name)
{
char path[MAX_PATH];
uint len = GetSystemDirectory(path, MAX_PATH);
if (len len + strlen(name) + 1 MAX_PATH) {
path[len] = '\\';
strcpy(path[len + 1], name);
return LoadLibrary(path);
}
else
return 0;
}
static void
load_dwm_funcs(void)
{
HMODULE dwm = load_sys_library(dwmapi.dll);
if (dwm) {
pDwmIsCompositionEnabled =
(void *)GetProcAddress(dwm, DwmIsCompositionEnabled);
pDwmExtendFrameIntoClientArea =
(void *)GetProcAddress(dwm, DwmExtendFrameIntoClientArea);
}
}
void
win_set_timer(void (*cb)(void), uint ticks)
{ SetTimer(wnd, (UINT_PTR)cb, ticks, null); }
void
win_set_title(char *title)
{
if (title_settable) {
wchar wtitle[strlen(title) + 1];
if (cs_mbstowcs(wtitle, title, lengthof(wtitle)) = 0)
SetWindowTextW(wnd, wtitle);
}
}
void
win_copy_title(void)
{
int len = GetWindowTextLengthW(wnd);
wchar title[len + 1];
len = GetWindowTextW(wnd, title, len + 1);
win_copy(title, 0, len + 1);
}
void
win_prefix_title(const char * prefix)
{
int len = GetWindowTextLengthW(wnd);
wchar ptitle[strlen(prefix) + len + 1];
int plen = cs_mbstowcs(ptitle, prefix, lengthof(ptitle));
wchar * title = ptitle[plen];
len = GetWindowTextW(wnd, title, len + 1);
SetWindowTextW(wnd, ptitle);
}
/*
* Title stack (implemented as fixed-size circular buffer)
*/
static wstring titles[16];
static uint titles_i;
void
win_save_title(void)
{
int len = GetWindowTextLengthW(wnd);
wchar *title = newn(wchar, len + 1);
GetWindowTextW(wnd, title, len + 1);
delete(titles[titles_i]);
titles[titles_i++] = title;
if (titles_i == lengthof(titles))
titles_i = 0;
}
void
win_restore_title(void)
{
if (!titles_i)
titles_i = lengthof(titles);
wstring title = titles[--titles_i];
if (title) {
SetWindowTextW(wnd, title);
delete(title);
titles[titles_i] = 0;
}
}
/*
* Switch to next or previous application window in z-order
*/
static HWND first_wnd, last_wnd;
static BOOL CALLBACK
wnd_enum_proc(HWND curr_wnd, LPARAM unused(lp)) {
if (curr_wnd != wnd !IsIconic(curr_wnd)) {
WINDOWINFO curr_wnd_info;
curr_wnd_info.cbSize = sizeof(WINDOWINFO);
GetWindowInfo(curr_wnd, curr_wnd_info);
if (class_atom == curr_wnd_info.atomWindowType) {
first_wnd = first_wnd ?: curr_wnd;
last_wnd = curr_wnd;
}
}
return true;
}
void
win_switch(bool back, bool alternate)
{
first_wnd = 0, last_wnd = 0;
EnumWindows(wnd_enum_proc, 0);
if (first_wnd) {
if (back)
first_wnd = last_wnd;
else
SetWindowPos(wnd, last_wnd, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE
| (alternate ? SWP_NOZORDER : SWP_NOREPOSITION));
BringWindowToTop(first_wnd);
}
}
static void
get_monitor_info(MONITORINFO *mip)
{
HMONITOR mon = MonitorFromWindow(wnd, MONITOR_DEFAULTTONEAREST);
mip-cbSize = sizeof(MONITORINFO);
GetMonitorInfo(mon, mip);
}
/*
* Minimise or restore the window in response to a server-side
* request.
*/
void
win_set_iconic(bool iconic)
{
if (iconic ^ IsIconic(wnd))
ShowWindow(wnd, iconic ? SW_MINIMIZE : SW_RESTORE);
}
/*
* Move the window in response to a server-side request.
*/
void
win_set_pos(int x, int y)
{
trace_resize((--- win_set_pos %d %d\n, x, y));
if (!IsZoomed(wnd))
SetWindowPos(wnd, null, x, y, 0, 0, SWP_NOSIZE | SWP_NOZORDER);
}
/*
* Move the window to the top or bottom of the z-order in response
* to a server-side request.
*/
void
win_set_zorder(bool top)
{
SetWindowPos(wnd, top ? HWND_TOP : HWND_BOTTOM, 0, 0, 0, 0,
SWP_NOMOVE | SWP_NOSIZE);
}
bool
win_is_iconic(void)
{
return IsIconic(wnd);
}
void
Re: [ANNOUNCEMENT] Update: mintty 2.1.2
Am 27.07.2015 um 17:58 schrieb Houder: Hi Thomas, Moving load_dwm_funcs() did the trick ... Thanks again for your analysis. In Control Panel → Performance Information and Tools → Adjust visual effects, it is only the last of the flags, ☐ Use visual styles on windows and buttons, that makes the difference; if deselected, mintty crashes if called from a console or somehow doubly isolated by (setsid mintty ). Apparently, LoadLibrary does not propagate to a forked thread; however, the result was kept static, so being called on a wrong assumption... A release with the fix will follow soon. Thomas --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: [ANNOUNCEMENT] Update: mintty 2.1.2
Thomas Wolff sent the following at Thursday, July 23, 2015 6:15 PM mintty 2.1.2 is an update in response to a number of crash reports under unclear circumstances; mintty only detaches from the caller's terminal if the option -D is given Neither man mintty nor mintty --help document the new -D option. Thanks, - Barry Disclaimer: Statements made herein are not made on behalf of NIAID.
[Attn Maintainer] stow
The update to Perl 5.22 is planned for the end of this week. Please notify immediately if you cannot provide the updated packages indicated below by then to your package upload area on cygwin.com. Your following packages contain sub-packages that need an update or re-release using Perl version 5.22: stow(perl-stow) Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
[Attn Maintainer] biber
The update to Perl 5.22 is planned for the end of this week. Please notify immediately if you cannot provide the updated packages indicated below by then to your package upload area on cygwin.com. Your following packages place Perl modules into vendor_perl and need an update or re-release using Perl version 5.22: biber [I understand you are already standby with the packages.] Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
[Attn Maintainer] git git-svn
The update to Perl 5.22 is planned for the end of this week. Please notify immediately if you cannot provide the updated packages indicated below by then to your package upload area on cygwin.com. Your following packages place Perl modules into vendor_perl and need an update or re-release using Perl version 5.22: git git-svn Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
[Attn Maintainer] pristine-tar sendxmpp grepmail
The update to Perl 5.22 is planned for the end of this week. Please notify immediately if you cannot provide the updated packages indicated below by then to your package upload area on cygwin.com. Your following packages place Perl modules into perl_vendor and need an update or re-release using Perl version 5.22: pristine-tar sendxmpp Your following packages place Perl modules into site_perl, which needs to be corrected to vendor_perl and need an update or re-release using Perl version 5.22: grepmail Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
RE: Cygwin Shell Fails to Start when Enabling High Address
Hi, We are revisiting our issue with running Cygwin by enabling the AllocationPreference registry to run in high address. We’re hoping some clarification from our colleague could help shed some light on our situation. “A major part of the work we did in the NT64 port was making sure that 64-bit pointers are not truncated to 32 bits. Most of the time you can get away with a truncated pointer because the address is in the lower 4GB of the address space and the upper 32 bits of the 64-bit pointer are not used. The AllocationPreference=0x10 setting forces memory allocations to use addresses above 4GB so that the upper 32 bits of 64-bit pointers are used. This can uncover bugs that would otherwise not be found until a process has used a lot of memory. Rather than stressing the machines by having every test allocate a ton of memory we can use this setting to accomplish the same thing. This testing has found several bugs in existing code and it helps guard against developers making the mistake of truncating pointers in new code.” This is a setting supported by Microsoft (see below). The AllocationPreference registry setting is documented on Microsoft’s website: https://msdn.microsoft.com/en-us/library/windows/hardware/dn613975(v=vs.85).aspx Usually, VirtualAlloc returns virtual addresses in low - high order. So, unless your process allocates a lot of memory or it has a very fragmented virtual address space, it will never get back very high addresses. This is possibly hiding bugs related to high addresses. There is a simple way to force allocations in top - down order in Windows Server 2003, Datacenter Edition and Enterprise Edition operating systems and this can reveal important bugs. It’s important that we have this registry enabled for our work and if your answer is still the same as before, will getting a support contract enable us to get this capability? Thanks, Ben Cao -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Corinna Vinschen Sent: Tuesday, February 24, 2015 4:34 PM To: cygwin@cygwin.com Subject: Re: Cygwin Shell Fails to Start when Enabling High Address Hi Benjamin, On Feb 24 19:58, Benjamin Cao wrote: Hi, I had to enable high address for some machines for testing. I set the AllocationPreference registry key to be 0X10. Cygwin doesn't support this AllocationPreference registry setting. Cygwin and thus Cygwin applications(*) are already large address aware. Cygwn uses large address regions automatically if available, but it's essential that Cygwin itself can decide how and what to use them for. Cygwin will also use MEM_TOP_DOWN allocations in certain system calls (e.g. mmap) but this, too, is crafted to avoid collisions, and Cygwin needs full control over this behaviour. In general, Cygwin needs as much control over memory allocations as possible in Windows for several reasons, mainly for the sake of fork and exec calls. So, having said that, AllocationPreference 0x10 breaks Cygwin's memory handling. Therefore, don't use it in conjunction with Cygwin applications. Corinna (*) There are exceptions, of course. 32 bit applications using the high bit of addresses for dubious reasons exist. Of course they deserve to be broken. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [ANNOUNCEMENT] Update: mintty 2.1.2
On Jul 27 19:44, Thomas Wolff wrote: Am 27.07.2015 um 17:58 schrieb Houder: Hi Thomas, Moving load_dwm_funcs() did the trick ... Thanks again for your analysis. In Control Panel → Performance Information and Tools → Adjust visual effects, it is only the last of the flags, ☐ Use visual styles on windows and buttons, that makes the difference; if deselected, mintty crashes if called from a console or somehow doubly isolated by (setsid mintty ). Apparently, LoadLibrary does not propagate to a forked thread; Forked process, I hope :) No, it doesn't. Loading a library is purly process lokal on Windows. Cygwin DLLs(*) have special startup code which allows to register them in the process and to re-load them in the child process at fork time. (*) Actually, any DLL using this special entry point would work. Native Windows DLLs just don't, usually :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp2E7txqlYTC.pgp Description: PGP signature
[Attn Maintainer] subversion net-snmp
The update to Perl 5.22 is planned for the end of this week. Please notify immediately if you cannot provide the updated packages indicated below by then to your package upload area on cygwin.com. Your following packages contain sub-packages that need an update or re-release using Perl version 5.22: subversion (subversion-perl) net-snmp(net-snmp-perl) [I don't know how difficult that is to do quickly, but maybe consider renaming these packages perl-net-snmp and perl-subversion.] Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
[Attn Maintainer] ming
The update to Perl 5.22 is planned for the end of this week. Please notify immediately if you cannot provide the updated packages indicated below by then to your package upload area on cygwin.com. Your following packages contain sub-packages that need an update or re-release using Perl version 5.22: ming(perl-ming) [Volker has indicated he's away and Yaakov offered to do the update. please respond if that's still valid.] Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
[Attn Maintainer] perl-Cairo, perl-Glib, perl-Gnome2, perl-Gtk2, perl-Tk, etc.
The update to Perl 5.22 is planned for the end of this week. Please notify immediately if you cannot provide the updated packages indicated below by then to your package upload area on cygwin.com. Your following packages need to be re-released or updated using Perl version 5.22: perl-Authen-SASL perl-Cairo perl-Cairo-GObject perl-Glib perl-Glib-Object-Introspection perl-Gnome2 perl-Gnome2-Canvas perl-Gnome2-GConf perl-Gnome2-Rsvg perl-Gnome2-VFS perl-Gnome2-Vte perl-Gnome2-Wnck perl-GStreamer perl-GStreamer-Interfaces perl-Gtk2 perl-Gtk2-GladeXML perl-Gtk2-Notify perl-Gtk2-SourceView2 perl-Gtk2-Spell perl-Gtk2-Unique perl-Gtk2-WebKit perl-Gtk3 perl-MailTools perl-Net-SMTP-SSL perl-Pango perl-PAR-Packer perl-SGMLSpm perl-Tk perl-Tk-Canvas-GradientColor perl-Tk-ColoredButton perl-Tk-EntryCheck perl-Tk-Getopt perl-Tk-Pod Your following packages contain sub-packages that need an update or re-release using Perl version 5.22: graphviz(perl-gv) libproxy(perl-Net-Libproxy) xfconf (perl-Xfce4-Xfconf) zinnia (perl-zinnia) Your following packages place Perl modules into vendor_perl and need an update or re-release using Perl version 5.22: po4a Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
[Attn Maintainer] amanda
The update to Perl 5.22 is planned for the end of this week. Please notify immediately if you cannot provide the updated packages indicated below by then to your package upload area on cygwin.com. Your following packages place Perl modules into vendor_perl and need an update or re-release using Perl version 5.22: amanda Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
[Attn Maintainer] irssi GraphicsMagick ImageMagick
The update to Perl 5.22 is planned for the end of this week. Please notify immediately if you cannot provide the updated packages indicated below by then to your package upload area on cygwin.com. Your following packages contain sub-packages that need an update or re-release using Perl version 5.22: perl-Graphics-Magick perl-Image-Magick Your following packages place Perl modules into vendor_perl and need an update or re-release using Perl version 5.22: irssi [I understand that the updates are already available as test versions. This is a reminder that the test packages need to be made current when Perl gets updated.] Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: Cygwin Shell Fails to Start when Enabling High Address
On Jul 27 18:41, Benjamin Cao wrote: Hi, We are revisiting our issue with running Cygwin by enabling the AllocationPreference registry to run in high address. We’re hoping some clarification from our colleague could help shed some light on our situation. “A major part of the work we did in the NT64 port was making sure that 64-bit pointers are not truncated to 32 bits. Most of the time you can get away with a truncated pointer because the address is in the lower 4GB of the address space and the upper 32 bits of the 64-bit pointer are not used. The AllocationPreference=0x10 setting forces memory allocations to use addresses above 4GB so that the upper 32 bits of 64-bit pointers are used. This can uncover bugs that would otherwise not be found until a process has used a lot of memory. Rather than stressing the machines by having every test allocate a ton of memory we can use this setting to accomplish the same thing. This testing has found several bugs in existing code and it helps guard against developers making the mistake of truncating pointers in new code.” This is a setting supported by Microsoft (see below). The AllocationPreference registry setting is documented on Microsoft’s website: https://msdn.microsoft.com/en-us/library/windows/hardware/dn613975(v=vs.85).aspx Usually, VirtualAlloc returns virtual addresses in low - high order. So, unless your process allocates a lot of memory or it has a very fragmented virtual address space, it will never get back very high addresses. This is possibly hiding bugs related to high addresses. There is a simple way to force allocations in top - down order in Windows Server 2003, Datacenter Edition and Enterprise Edition operating systems and this can reveal important bugs. It’s important that we have this registry enabled for our work and if your answer is still the same as before, will getting a support contract enable us to get this capability? So you're talking about a 64 bit application? You didn't say so in your OP. Anyway, I'm very much puzzled. Either your application is a native Windows, non-Cygwin application using VirtualAlloc. Then it doesn't matter how Cygwin handles memory for it's own processes to you since the memory allocations in your process have nothing to do with Cygwin's allocation style. Or it's a POSIX application ported to Cygwin. In this case you shouldn't use VirtualAlloc but malloc or mmap, and the way memory gets allocated is not in your realm, but in Cygwin's. Also, on 64 bit Cygwin all memory (except thread stacks) is allocated beyond 0x1:000 anyway. On 32 bit with 3gb/4gt setting or on WOW64, the heap used for malloc allocations 256K is beyond 0x8000 and mmap s are allocated top down, so they start beyond 0x8000 as well. So a Cygwin application is either high memory clean or it will crash. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgptXd5vFfeeg.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Update: mintty 2.1.2
On Jul 27 22:44, Houder wrote: On Jul 27 19:44, Thomas Wolff wrote: Am 27.07.2015 um 17:58 schrieb Houder: Hi Thomas, Moving load_dwm_funcs() did the trick ... Thanks again for your analysis. In Control Panel â Performance Information and Tools â Adjust visual effects, it is only the last of the flags, â Use visual styles on windows and buttons, that makes the difference; if deselected, mintty crashes if called from a console or somehow doubly isolated by (setsid mintty ). Apparently, LoadLibrary does not propagate to a forked thread; Forked process, I hope :) No, it doesn't. Loading a library is purly process lokal on Windows. Cygwin DLLs(*) have special startup code which allows to register them in the process and to re-load them in the child process at fork time. (*) Actually, any DLL using this special entry point would work. Native Windows DLLs just don't, usually :} Ha, Corinna, you are the expert here, of course :-) From MSDN I learned (LoadLibrary() ): Module handles are not global or inheritable. A call to LoadLibrary by one process does not produce a handle that another process can use in calling GetProcAddress (as an example). The other process must make its OWN call to LoadLibrary for the module before calling GetProcAddress Well, ok, alright, that makes sense ... However, if pDwmIsCompositionEnabled() returns 1, which will be the case if one has selected 'Windows 7' i.s.o. 'Windows Basic' (Personalization), as an example ... it turned out to be possible to invoke load_dwm_funcs() (i.e. LoadLibrary() ) before the fork to a child withOUT a crash of the child ! After all, it is Windows ? What if the DLL is preloaded into processes with certain settings, e.g. by some other Windows DLL? LoadLibrary won't indicate if the DLL has been loaded by this call or earlier. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpvr9Yq2szdW.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Update: mintty 2.1.2
On Jul 27 19:44, Thomas Wolff wrote: Am 27.07.2015 um 17:58 schrieb Houder: Hi Thomas, Moving load_dwm_funcs() did the trick ... Thanks again for your analysis. In Control Panel â Performance Information and Tools â Adjust visual effects, it is only the last of the flags, â Use visual styles on windows and buttons, that makes the difference; if deselected, mintty crashes if called from a console or somehow doubly isolated by (setsid mintty ). Apparently, LoadLibrary does not propagate to a forked thread; Forked process, I hope :) No, it doesn't. Loading a library is purly process lokal on Windows. Cygwin DLLs(*) have special startup code which allows to register them in the process and to re-load them in the child process at fork time. (*) Actually, any DLL using this special entry point would work. Native Windows DLLs just don't, usually :} Ha, Corinna, you are the expert here, of course :-) From MSDN I learned (LoadLibrary() ): Module handles are not global or inheritable. A call to LoadLibrary by one process does not produce a handle that another process can use in calling GetProcAddress (as an example). The other process must make its OWN call to LoadLibrary for the module before calling GetProcAddress Well, ok, alright, that makes sense ... However, if pDwmIsCompositionEnabled() returns 1, which will be the case if one has selected 'Windows 7' i.s.o. 'Windows Basic' (Personalization), as an example ... it turned out to be possible to invoke load_dwm_funcs() (i.e. LoadLibrary() ) before the fork to a child withOUT a crash of the child ! After all, it is Windows ? No doubt, it will have been documented somewhere (DWM) ... As an follow-up: The companion to pDwmIsCompositionEnabled(), i.e. pDwmExtendFrameIntoClientArea() made the child crash -- in update_glass(), Thomas, when 'Windows Basic' had been selected. Both function pointers always showed the same addresses, but when 'Windows Basic' had been selected, they turned out to be a jump into 'void'. Henri -- 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: [Attn Maintainer] git git-svn
On 27/07/2015 20:45, Achim Gratz wrote: The update to Perl 5.22 is planned for the end of this week. Please notify immediately if you cannot provide the updated packages indicated below by then to your package upload area on cygwin.com. Your following packages place Perl modules into vendor_perl and need an update or re-release using Perl version 5.22: git git-svn I'm just waiting for it to finish running through the test suite before I upload :)
Re: [ANNOUNCEMENT] Update: mintty 2.1.2
On Jul 27 22:44, Houder wrote: On Jul 27 19:44, Thomas Wolff wrote: Am 27.07.2015 um 17:58 schrieb Houder: Hi Thomas, Moving load_dwm_funcs() did the trick ... Thanks again for your analysis. In Control Panel â Performance Information and Tools â Adjust visual effects, it is only the last of the flags, â Use visual styles on windows and buttons, that makes the difference; if deselected, mintty crashes if called from a console or somehow doubly isolated by (setsid mintty ). Apparently, LoadLibrary does not propagate to a forked thread; Forked process, I hope :) No, it doesn't. Loading a library is purly process lokal on Windows. Cygwin DLLs(*) have special startup code which allows to register them in the process and to re-load them in the child process at fork time. (*) Actually, any DLL using this special entry point would work. Native Windows DLLs just don't, usually :} Ha, Corinna, you are the expert here, of course :-) From MSDN I learned (LoadLibrary() ): Module handles are not global or inheritable. A call to LoadLibrary by one process does not produce a handle that another process can use in calling GetProcAddress (as an example). The other process must make its OWN call to LoadLibrary for the module before calling GetProcAddress Well, ok, alright, that makes sense ... However, if pDwmIsCompositionEnabled() returns 1, which will be the case if one has selected 'Windows 7' i.s.o. 'Windows Basic' (Personalization), as an example ... it turned out to be possible to invoke load_dwm_funcs() (i.e. LoadLibrary() ) before the fork to a child withOUT a crash of the child ! After all, it is Windows ? What if the DLL is preloaded into processes with certain settings, e.g. by some other Windows DLL? LoadLibrary won't indicate if the DLL has been loaded by this call or earlier. Sigh ... you got me, I am not familiar with Windows ... Anything can happen under the hood, and I will not know. I only know, that dwmapi.dll is the only .dll that is loaded by mintty at run time ... and that is was required to happen after the fork in my case. (my case being: 'Windows Basic' (Personalization) ) Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Update: mintty 2.1.2
On Jul 27 19:44, Thomas Wolff wrote: Am 27.07.2015 um 17:58 schrieb Houder: Hi Thomas, Moving load_dwm_funcs() did the trick ... Thanks again for your analysis. In Control Panel â Performance Information and Tools â Adjust visual effects, it is only the last of the flags, â Use visual styles on windows and buttons, that makes the difference; if deselected, mintty crashes if called from a console or somehow doubly isolated by (setsid mintty ). Apparently, LoadLibrary does not propagate to a forked thread; Forked process, I hope :) No, it doesn't. Loading a library is purly process lokal on Windows. Cygwin DLLs(*) have special startup code which allows to register them in the process and to re-load them in the child process at fork time. (*) Actually, any DLL using this special entry point would work. Native Windows DLLs just don't, usually :} Ha, Corinna, you are the expert here, of course :-) From MSDN I learned (LoadLibrary() ): Module handles are not global or inheritable. A call to LoadLibrary by one process does not produce a handle that another process can use in calling GetProcAddress (as an example). The other process must make its OWN call to LoadLibrary for the module before calling GetProcAddress Well, ok, alright, that makes sense ... However, if pDwmIsCompositionEnabled() returns 1, which will be the case if one has selected 'Windows 7' i.s.o. 'Windows Basic' (Personalization), as an example ... it turned out to be possible to invoke load_dwm_funcs() (i.e. LoadLibrary() ) before the fork to a child withOUT a crash of the child ! After all, it is Windows ? No doubt, it will have been documented somewhere (DWM) ... Henri -- 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: [Attn Maintainer] stow
The update to Perl 5.22 is planned for the end of this week. Please notify immediately if you cannot provide the updated packages indicated below by then to your package upload area on cygwin.com. Your following packages contain sub-packages that need an update or re-release using Perl version 5.22: stow (perl-stow) Hi Achim. Sure, I'm happy to do it. But can you please explain in more detail what you're looking for? ATM when I build perl-Stow, the files go into /usr/lib/perl5/vendor_perl/5.14. If I understand right, you're asking me to provide an updated package where the files will go into /usr/lib/perl5/vendor_perl/5.22 instead. Correct? Leave aside that it seems brain-dead that I should have to rebuild my package for such a triviality. Wouldn't it be nice if I could put the files into, say, /usr/lib/perl5/vendor_perl, and not have to rebuild my package every time there's a new point release of Perl? But okay, I'll rebuild it. So are you asking me to first wait until Perl 5.22 comes out, then rebuild the package and release it afterwards? Or to manually change where the files go, and release the update at the same time as Perl 5.22? And doesn't this mean that perl-Stow-2.2.0-3 should be made to depend explicitly on perl version 5.22? Which upset doesn't currently support, IIRC. I mean, seriously, this seems like a lot of dumb work to me. Not that I blame you for that. On the contrary, I greatly appreciate your work as the Perl maintainer. I'm just trying to figure out how to make it work with the least amount of pain. Thanks, Andrew
Re: [Attn CVS maintainer] Re: CVS checkout with absolute path fails in 32-bit build
On Tue, Jul 21, 2015 at 11:29:33PM +0200, Marco Atzeri wrote: I just uploaded a cvs-1.11.23-2 version as test for 32bit only. I missed the as test the first time I read this email, and thought all my mirrors were being incredibly slow to pick up the change... It uses all the patches available in Fedora. cvs-1.11.23-1 patches were not enough due to some change in info building. Could you check if does it solve your problem ? I've just confirmed: with cvs 1.11.23-2, t9200 of the Git test suite is passing just fine on 32-bit Cygwin. Thanks! -- 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
Uploading packages built against Perl 5.2.2 [Was: [ITA] Perl distributions (in preparation of Perl 5.22)]
On Sun, Jul 05, 2015 at 08:02:41AM +0200, Achim Gratz wrote: David Rothenberger writes: I've rebuilt the package as curr and not test and uploaded to my area. I did not create the !ready file. Is this the right way to do this? Or should I release a test package? As long as you remember what you did it's going to be OK. A test package might only be needed if someone else asks for it or you need testers. Is there a consensus on the way to upload files ready for Perl 5.22 to be made available? The Git packages are ready to go, but I'm not sure if I should be uploading them without a !ready file, or as a test release. Or is the idea just that we're going to try to coordinate the many maintainers worldwide to all release at the same time on Friday? As that'll mean it doesn't matter that there's no consensus, it just seems like it'll also be inordinately painful, too.
Re: [ANNOUNCEMENT] Update: mintty 2.1.2
Am 27.07.2015 um 20:08 schrieb Buchbinder, Barry (NIH/NIAID) [E]: Thomas Wolff sent the following at Thursday, July 23, 2015 6:15 PM mintty 2.1.2 is an update in response to a number of crash reports under unclear circumstances; mintty only detaches from the caller's terminal if the option -D is given Neither man mintty nor mintty --help document the new -D option. Not strictly an excuse, but the -D option was a hotfix to be dropped again in the next version. -- Thomas --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus -- 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: [Attn Maintainer] stow
Andrew Schulman writes: ATM when I build perl-Stow, the files go into /usr/lib/perl5/vendor_perl/5.14. If I understand right, you're asking me to provide an updated package where the files will go into /usr/lib/perl5/vendor_perl/5.22 instead. Correct? Yes. It will automatically do that when you build it again with Perl 5.22. Leave aside that it seems brain-dead that I should have to rebuild my package for such a triviality. Wouldn't it be nice if I could put the files into, say, /usr/lib/perl5/vendor_perl, and not have to rebuild my package every time there's a new point release of Perl? The thing here is that we're making quite a jump from 5.14 to 5.22 (four major upstream releases) with a bunch of user-visible changes and while it would have been possible to make 5.22 look modules up in the 5.14 directories and it would generally work, there were too many changes for _all_ of that to work correctly and some of these errors would likely have been quite non-obvious. So I decided that things must be rebuilt with 5.22 for this update specifically. But okay, I'll rebuild it. So are you asking me to first wait until Perl 5.22 comes out, then rebuild the package and release it afterwards? Or to manually change where the files go, and release the update at the same time as Perl 5.22? The idea was that you install the pre-release Perl that was published specifically to facilitate this rebuild. And doesn't this mean that perl-Stow-2.2.0-3 should be made to depend explicitly on perl version 5.22? Which upset doesn't currently support, IIRC. To be honest, I've been thinking about making a perl522 instead of just a perl package, but that looked even less appealing, given that the next few updates of Perl quite likely don't require such jumping through hoops. I mean, seriously, this seems like a lot of dumb work to me. Sorry. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [Attn Maintainer] git git-svn
Adam Dinwoodie writes: I'm just waiting for it to finish running through the test suite before I upload :) Thank you. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: Processes randomly get stuck
On Jul 26 12:56, Ismail Donmez wrote: Hi, $ uname -a CYGWIN_NT-10.0 ux31a 2.2.0(0.289/5/3) 2015-07-23 20:41 x86_64 Cygwin For the last week or so ssh/zsh processes are randomly gets into defunct state, that is $ cat /proc/7232/cmdline defunct $ cat /proc/7232/status Name: zsh State: S (sleeping) Tgid: 7232 Pid:7232 PPid: 5172 Uid:197609 197609 197609 197609 Gid:197609 197609 197609 197609 VmSize: 7556 kB VmLck: 0 kB VmRSS: 10860 kB VmData: 2140 kB VmStk: 0 kB VmExe: 0 kB VmLib: 4644 kB SigPnd: SigBlk: SigIgn: Same happens with ssh, and after some time like 5 minutes or so it goes back to the normal state. I wonder if anyone has been experiencing something similar? There's no change in 2.2.0 which might explain this, but still, did you try to downgrade to 2.1.0? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpN6nv78fYr8.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Update: mintty 2.1.2
On Sat, Jul 25, 2015 at 10:15 PM, Houder wrote: ... Please, make a mental picture of the check boxes at your place at 'control panel performance information and tools adjust visual effects'. I'll bet, all check boxes for eye candy has been checked at your place; NONE of them are checked at my place ... (I am an old fashioned guy, who wants his 8 cores to do useful things) They do, even with the checkboxes on: http://blogs.msdn.com/b/oldnewthing/archive/2013/03/27/10405554.aspx Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- 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: [PATCH] winsup/cygwin: Protect fork() against dll- and exe-updates.
Hi Michael,
On Jul 24 17:43, Michael Haubenwallner wrote:
Hi!
When starting to port Gentoo Prefix to Cygwin, the first real problem
discovered is that fork() does use the original executable's location
to Create the child's Process, probably finding linked dlls that just
have emerged in the current directory (sth. like /my/prefix/usr/bin),
causing Loaded different DLL with same basename in forked child errors.
Unfortunately there's some red tape to get over with, first. We need a
copyright assignment from you before we can go much further. See
https://cygwin.com/contrib.html, Before you get started. Please fill
out the standard assignment form and send the signed PDF to the address
given therein.
Diving into the details, I'm coming up with (a patch-draft based on) the
idea to create hardlinks for the binaries-in-use into some cygwin-specific
directory, like \proc\ntpid\object\ ('ve seen this name on AIX),
and use these hardlinks instead to create the new child's process.
Thoughts so far?
Well, yes. Off the top of my head a couple of potential problems come
to mind:
- /proc is already available as virtual filesystem as on Linux. Reusing
it for some purposes is ok, but in this case we're talking about a
real directory of the same name, which then would be hidden beneath
the virtual one. Is that deliberate? The directory wouldn't be
accessible from Cygwin applications while native Windows apps would
see the dir. I think hidden is bad. Something like this should take
place in a visible cache dir. /var/cache or /var/spool come to mind.
Also, using the Windows PID as dir name seems a bit weird, given that
the virtual /proc obviously uses the Cygwin PID. This sounds like a
source for confusion.
- What about running Cygwin on filesystems not supporting hardlinks,
like FAT?
- There's a meme along the lines of Why is Cygwin s Slow!!!1!!11.
The most important factor for this slowness is the way fork() has to
be emulated. The method you're proposing would add to the overhead by
having to create hardlinks on fork and deleting them again at exit or
execve time.
Did you run tests to find out the cost of this additional overhead?
For now, when cygroot\proc\ directory does exist, the patch (roughly) does:
For /bin/bash.exe, cygwin1.dll creates these hardlinks at process startup:
\proc\ntpid\object\bash.exe - /bin/bash.exe
\proc\ntpid\object\bash.exe.local (empty file for dll redirection)
\proc\ntpid\object\cygwin1.dll - /bin/cygwin1.dll
\proc\ntpid\object\cygreadline7.dll - /bin/cygreadline7.dll
And frok::parent then does:
CreateProcess(\proc\ntpid\object\bash.exe, /bin/bash.exe, ...)
Resulting in another \proc\ntpid\object\ directory with same hardlinks.
While attached patch does work so far already, there's a few issues:
*) dll-redirection for LoadLibrary using app.exe.local file does operate on
the dll's basename only, breaking perl's Hash::Util and List::Util at
least.
So creating hardlinks for dynamically loaded dlls is disabled for now.
Eventually, manifests and/or app.exe.config could help here, but I'm still
failing to really grok them...
Hmm. The DLLs are loaded dynamically anyway, so they will be loaded
dynamically in the child as well in dll_list::load_after_fork_impl. Why
not simply hardlinking them using a unique filename (e.g. using the
inode number), storing the unique number or name in the dll struct and
then calling LoadLibrary on this name?
*) Who can clean up \proc\ntpid\ directory after power-loss or similar?
For now, if stale \proc\ntpid\ is found, it is removed beforehand.
But when this was from a different user, cleanup will fail. However,
using \proc\S-current-user-id\ntpid\ instead could help here...
Yes, that seems necessary. The requirement to remove a complete
directory on process startup is a lot of effort, though. I'm feeling a
sweat attack coming...
*) Is it really necessary to create these hardlinks in the real filesystem?
I could imagine to create them directly in $Recycle.bin instead, or some
(other) memory-only thing...
Uh, well, they are hardlinks after all. They must be created on the
same filesystem.
Thoughts welcome!
In general I like the basic idea behind this. But given the overhead it
adds to the already slow fork, I'm rather reluctant. I'm sure this
needs at least a lot more discussion (for which the cygwin-developers
mailing list, redirected to, would be better suited). For instance:
- What if a EXE/DLL is replace more than once during the lifetime of
a process?
- What about reducing the overhead by implementing some kind of generic
exe/dll cache used by all processes? It would reduce the requirement
to cleanup, reduce the footprint of the cache, speed up subsequent
forks.
- Given that the /bin directory alone can be easily 0.5 Gigs and more,
the cache(s) can take as much memory. This
Re: Ok, just a request for explanation/clarification then ...
On Jul 25 14:53, Houder wrote: Hi Corinna, I hesitate to ask ... yes, I am aware you have enough on your plate. If you cannot explain the phenomenon from the top of your head, let it rest, please. Please, ignore request ... For the record: although still present when using v203 of mintty, it appears to have gone when using v212. My apologies for the noise. No worries. I'm glad you found it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpjNdDusyiZa.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Update: mintty 2.1.2
On Sat, Jul 25, 2015 at 10:15 PM, Houder wrote: ... Please, make a mental picture of the check boxes at your place at 'control panel performance information and tools adjust visual effects'. I'll bet, all check boxes for eye candy has been checked at your place; NONE of them are checked at my place ... (I am an old fashioned guy, who wants his 8 cores to do useful things) They do, even with the checkboxes on: http://blogs.msdn.com/b/oldnewthing/archive/2013/03/27/10405554.aspx Thanks for the link ... ;-) So, I am of those guys who thinks he is awesomely clever. Right? because enthusiasts who think they are so awesomely clever, love disabling anything that makes the computer look pretty, because they're convinced that effort making the computer look pretty is clearly done at the expense of performance. As I do not want to be stupid, I enabled for best appearance :-)) As I totally do not appreciate the eye candy I got after enabling for best appearance , I decided to select 'Windows Basic' (Personalization). Guess what? 'mintty -D' crashes ... Henri Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- 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 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
