Re: [h-e-w] cygwin-64 2.3.1. bash fails when running under FSF emacs 24.5
> Date: Thu, 26 Nov 2015 22:20:18 +0100 > From: Dominique de Waleffe > > So... started my homework... Got fresh w10 vm, put cygwin64 and both > versions of emacs 24.4 and 24.5 from fsf ftp onto it > > And trying to start bash as shell fails under both versions! > > => I was mistaken in the origin of my instance of 24.4 (it must have > come from another source, and I do not remember which) > It says: GNU Emacs 24.4.1 (x86_64-w64-mingw32) of 2014-10-21 on KAEL > > => both versions from fsf ftp appear to be compiled using mingw > GNU Emacs 24.5.1 (i686-pc-mingw32) of 2015-04-11 on LEG570 > GNU Emacs 24.4.1 (i686-pc-mingw32) of 2014-10-24 on LEG570 > > So the difference seems to be in the difference of mingw compilation mode. > > That's as far as I got tonight. Maybe someone has knowledge to share > about the cause and what to do about this? I'd say this is somehow related to 64-bit Cygwin programs being run by 32-bit native Windows programs. The version which works for you is a 64-bit executable, those that don't are 32-bit. Maybe there are compatibility issues vis-à-vis 64-bit Cygwin. -- 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
[ANNOUNCEMENT] Updated: doxygen-1.8.10-2
The following packages have been updated in the Cygwin distribution: * doxygen-1.8.10-2 * doxygen-doxywizard-1.8.10-2 Doxygen is a documentation system for C++, C, Java, Objective-C, IDL (Corba and Microsoft flavours) and to some extent PHP, C#, and D. This update contains a number of upstream patches. Dave. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 2.3.1: '/bin/kill -l 0' dumps core
Hi Michael, On Nov 26 16:32, mkwas...@web.de wrote: > Hi all, > > I have just discovered that the command '/bin/kill -l 0' dumps core where > bash's built in does not (well, it just displays 'T'...). > > NOTE: the signal spec after dash-ell is the number zero. > > Pls. find the output of cygcheck and the callstack attached to this mail. > > Short analysis: kill.cc: main() calls listsig() with arg "0". getsig() > gets called with same arg. getsig() build string "SIG0" in local buf > and gives that to strtosigno() which returns 0. > > Then I suspect the bug in line 96 of kill.cc, the end of getsig(): > if (!intsig && (strcmp (buf, "SIG0") != 0 && (strtol (in_sig, &p, 10) != 0 > || *p))) > intsig = -1; > return intsig; > > intsig should be set to -1 either if intsig == 0 or if buf is not "SIG0" > and strtol() returns 0 or fails, so line 96 should read > if (!intsig || (strcmp (buf, "SIG0") != 0 && (strtol (in_sig, &p, 10) != 0 > || *p))) > > This sets intsig to -1 and returns from getsig(). > > Without that change intsig would remain zero causing the SEGV in listsig() > in line 125 where puts() is called, so another security fix in strsigno() > appears to be necessary to avoid calling puts(sys_sigabbrev[0]+3); which > is most likely the cause of the SEGV (I could not find the array's > definition so I could not verify this). > > So line 125 > if (signo >= 0 && signo < NSIG) > should rather read > if (signo > 0 && signo < NSIG) > > Sorry but all I can provide this a simple patch (attached) but I'm unable > to test it myself. Thanks. I changed the patch slightly to get the same output as kill from util-linux: $ kill -l 0 0 I checked this in. Thanks for the report and the patch. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp22fMMJPTVz.pgp Description: PGP signature
Re: [h-e-w] cygwin-64 2.3.1. bash fails when running under FSF emacs 24.5
So... started my homework... Got fresh w10 vm, put cygwin64 and both versions of emacs 24.4 and 24.5 from fsf ftp onto it And trying to start bash as shell fails under both versions! => I was mistaken in the origin of my instance of 24.4 (it must have come from another source, and I do not remember which) It says: GNU Emacs 24.4.1 (x86_64-w64-mingw32) of 2014-10-21 on KAEL => both versions from fsf ftp appear to be compiled using mingw GNU Emacs 24.5.1 (i686-pc-mingw32) of 2015-04-11 on LEG570 GNU Emacs 24.4.1 (i686-pc-mingw32) of 2014-10-24 on LEG570 So the difference seems to be in the difference of mingw compilation mode. That's as far as I got tonight. Maybe someone has knowledge to share about the cause and what to do about this? Regards, D. # Dominique de Waleffe # ddewaleffe -at- gmail -dot- com On Thu, Nov 26, 2015 at 8:10 PM, Dominique de Waleffe wrote: > There never was any reason to do as I have so far always been able to > run a version of Emacs compiled without cygwin without any blocking > issue but still running cygwin tools under emacs (and that has been a > case for a very long time!). I have no religious opinion on this but > I don't see why I should add a dependency that, in "principle" should > not be needed. > > The previous build of Emacs on the gnu site was already build with > mingw and afaik it works. It is just that the current combination does > not, in my case. I have no clue as to which version of mingw is > involved in those two emacs builds. But maybe you're onto something > there... Do you have any suggestion as how to validate your > hypothesis? > > My goal is not to complain and just have a quick work around, I'd > rather report the issue and if possible help in resolving the issue... > I see that my download has finished... I'll setup this vm and try what > I can with it > > Regards, > > D. > > > > > # Dominique de Waleffe > # ddewaleffe -at- gmail -dot- com > > > > On Thu, Nov 26, 2015 at 7:00 PM, Achim Gratz wrote: >> Dominique de Waleffe writes: >>> Meanwhile, I'll make a VM with a fresh install of Win10 (v1511 x64) >>> and just Emacs + cygwin and see whether there is something fishy about >>> my current setup after the upgrades it went through... >> >> Is there any reason why you don't use the Emacs that comes with Cygwin? >> Rebasing Cygwin won't help a bit if some of the GNUwin or MinGW >> (depending on the build) librraies that Emacs is compiled with collide >> in that same address space. >> >> >> 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 >> >> -- >> 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
RE: Argument parsing with gcc compiled program
Sorry I should have specified, this is not bash as this happens with the gcc
compiled
program within a Command Prompt session.
K:\>a.exe -s something "something d\:\\hello"
Command-line arguments:
argv[0] a
argv[1] -s
argv[2] something
argv[3] something d\:\hello
CL: K:\sat-misc\src\sat-main\sat\src\wiz\a -s something "something d\:\hello"
==
For some reason when I compile a C program in gcc, double backslashes within
quotes are stripped.
But if I compile with Visual Studio this does not happen. I used a small test
program to demonstrate.
VS
c:\msvc2010_SP1\VC>a.exe -s something "something d\:\\hello"
Command-line arguments:
argv[0] a.exe
argv[1] -s
argv[2] something
argv[3] something d\:\\hello
CL: a.exe -s something "something d\:\\hello"
GCC
$ ./a.exe -s something "something d\:\\hello"
Command-line arguments:
argv[0] ./a
argv[1] -s
argv[2] something
argv[3] something d\:\hello
CL: K:\sat-misc\src\sat-main\sat\src\wiz\a -s something "something d\:\hello"
Is there some compiler option or setting I'm unaware of?
Thanks,
Glenn
===
#include
#include
int main( int argc, // Number of strings in array argv
char *argv[], // Array of command-line argument strings
char **envp ) // Array of environment variable strings
{
int count;
char *gcl;
// Display each command-line argument.
printf(" \nCommand-line arguments:\n" );
for( count = 0; count < argc; count++ )
printf( " argv[%d] %s\n", count, argv[count] );
gcl = GetCommandLine();
printf("CL: %s\n",gcl);
}
--
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: Argument parsing with gcc compiled program
On 26/11/2015 21:08, Gluszczak, Glenn wrote: For some reason when I compile a C program in gcc, double backslashes within quotes are stripped. But if I compile with Visual Studio this does not happen. I used a small test program to demonstrate. VS c:\msvc2010_SP1\VC>a.exe -s something "something d\:\\hello" Command-line arguments: argv[0] a.exe argv[1] -s argv[2] something argv[3] something d\:\\hello CL: a.exe -s something "something d\:\\hello" GCC $ ./a.exe -s something "something d\:\\hello" Command-line arguments: argv[0] ./a argv[1] -s argv[2] something argv[3] something d\:\hello CL: K:\sat-misc\src\sat-main\sat\src\wiz\a -s something "something d\:\hello" Is there some compiler option or setting I'm unaware of? Thanks, Glenn bash is stripping the double backslashes when using " , try ' $ ./a.exe -s something 'something d\:\\hello' Command-line arguments: argv[0] ./a argv[1] -s argv[2] something argv[3] something d\:\\hello CL: "E:\cygwin64\tmp\a.exe" -- 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: 64bit cygwin 2.4.0-0.4 hangs when pinging unresponsive host
On Nov 25 22:01, Marco Atzeri wrote: > > > On 25/11/2015 12:03, Marco Atzeri wrote: > >On 25/11/2015 08:06, Thomas Wolff wrote: > >>Am 24.11.2015 um 23:29 schrieb Marco Atzeri: > >>> > > > >>>... > >>>I assume it is an interaction with mintty. > >>Many problems of that kind attributed to mintty are actually problems > >>with cygwin or especially pty. > >>Please test also with another terminal (xterm, rxvt, ...). > >>Also some more details could be helpful as I cannot reproduce the issue > >>(output of `type ping`, actual host pinged). > >>-- > >>Thomas > > > >you are right is not a mintty only issue. > >Same happens in xterm > > > > > >$ which ping > >/usr/bin/ping > > > >$ ping 2.2.2.2 > >PING 2.2.2.2 (2.2.2.2): 56 data bytes > > > >It sticks here forever, CTRL+C ineffective. > >Process Explorer or Task Manager are needed to kill the process. > >Also kill -9 PID is ineffective > > > >On the old cygwin.bat (aka windows cmd) > >CTRL+C is effective > > > > 64 $ ping 2.2.2.2 > >PING 2.2.2.2 (2.2.2.2): 56 data bytes > > > >2.2.2.2 PING Statistics > >2 packets transmitted, 0 packets received, 100.0% packet loss > > > the problem seems restricted to the 64bit test version of cygwin. I think this is pure coincidence. After some hours debugging this problem it seems it's a race condition, architecture-independent and present since quite a while in Cygwin. In case of ping the race leads to a blocking socket function missing a signal arrived, thus the signal is never handled. This in turn blocks the next signal from being delivered. I have a potential fix, but I have to test it a bit. The signal code is pretty complicated... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpQj7Vz1XgA4.pgp Description: PGP signature
Argument parsing with gcc compiled program
For some reason when I compile a C program in gcc, double backslashes within
quotes are stripped.
But if I compile with Visual Studio this does not happen. I used a small
test program to demonstrate.
VS
c:\msvc2010_SP1\VC>a.exe -s something "something d\:\\hello"
Command-line arguments:
argv[0] a.exe
argv[1] -s
argv[2] something
argv[3] something d\:\\hello
CL: a.exe -s something "something d\:\\hello"
GCC
$ ./a.exe -s something "something d\:\\hello"
Command-line arguments:
argv[0] ./a
argv[1] -s
argv[2] something
argv[3] something d\:\hello
CL: K:\sat-misc\src\sat-main\sat\src\wiz\a -s something "something d\:\hello"
Is there some compiler option or setting I'm unaware of?
Thanks,
Glenn
===
#include
#include
int main( int argc, // Number of strings in array argv
char *argv[], // Array of command-line argument strings
char **envp ) // Array of environment variable strings
{
int count;
char *gcl;
// Display each command-line argument.
printf(" \nCommand-line arguments:\n" );
for( count = 0; count < argc; count++ )
printf( " argv[%d] %s\n", count, argv[count] );
gcl = GetCommandLine();
printf("CL: %s\n",gcl);
}
--
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: Ability to specify /cygdrive mount value in setup
On Nov 26 19:04, Achim Gratz wrote: > Corinna Vinschen writes: > > The right thing to do is to change the base-files package to utilize > > /proc/cygdrive. It's a vrtual symlink pointing to the actual cygdrive > > prefix currently in use. If these symlinks under /etc used the > > /proc/cygdrive symlink, they would work all the time, independenly of > > the actual cygdrive prefix. > > I was thinking of using a native symlink, but going through the procfs > seems cleaner. Native symlinks are no safe bet since they require special permissions. Won't work when running setup as non-admin user. > > Achim, any chance to tweak base-file accordingly? > > Noted, but it might take a while. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpEeAa4I002n.pgp Description: PGP signature
Re: [h-e-w] cygwin-64 2.3.1. bash fails when running under FSF emacs 24.5
There never was any reason to do as I have so far always been able to run a version of Emacs compiled without cygwin without any blocking issue but still running cygwin tools under emacs (and that has been a case for a very long time!). I have no religious opinion on this but I don't see why I should add a dependency that, in "principle" should not be needed. The previous build of Emacs on the gnu site was already build with mingw and afaik it works. It is just that the current combination does not, in my case. I have no clue as to which version of mingw is involved in those two emacs builds. But maybe you're onto something there... Do you have any suggestion as how to validate your hypothesis? My goal is not to complain and just have a quick work around, I'd rather report the issue and if possible help in resolving the issue... I see that my download has finished... I'll setup this vm and try what I can with it Regards, D. # Dominique de Waleffe # ddewaleffe -at- gmail -dot- com On Thu, Nov 26, 2015 at 7:00 PM, Achim Gratz wrote: > Dominique de Waleffe writes: >> Meanwhile, I'll make a VM with a fresh install of Win10 (v1511 x64) >> and just Emacs + cygwin and see whether there is something fishy about >> my current setup after the upgrades it went through... > > Is there any reason why you don't use the Emacs that comes with Cygwin? > Rebasing Cygwin won't help a bit if some of the GNUwin or MinGW > (depending on the build) librraies that Emacs is compiled with collide > in that same address space. > > > 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 > > -- > 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
Re: gfortran segfaults on "Hello world"
Thomas Koenig writes: […] Can you please post cygcheck output as per https://cygwin.com/problems.html 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 -- 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: Ability to specify /cygdrive mount value in setup
Corinna Vinschen writes: > The right thing to do is to change the base-files package to utilize > /proc/cygdrive. It's a vrtual symlink pointing to the actual cygdrive > prefix currently in use. If these symlinks under /etc used the > /proc/cygdrive symlink, they would work all the time, independenly of > the actual cygdrive prefix. I was thinking of using a native symlink, but going through the procfs seems cleaner. > Achim, any chance to tweak base-file accordingly? Noted, but it might take a while. 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 -- 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: Rounding off real (floating point) values - bash to awk
Lester Anderson writes: […] By now, none of what you ask has anything to do with Cygwin anymore. Please consider chosing a more appropriate forum for your questions. 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 -- 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
Fwd: Re: Rounding off real (floating point) values - bash to awk
On 11/26/2015 12:20 PM, Helmut Karlowski wrote:
---
On Thu, Nov 26, 2015 at 10:29 AM, Steven Penny wrote:
echo 3.7 | awk '{printf "%.0f", $0}'
Another option
awk 'BEGIN {printf "%.0f", ARGV[1]}' 3.7
#4:
printf "%3.0f\n" 3.7
Yes, while bash does not itself "do" floating point arithmetic,
it does have a printf builtin. Also, you can do computations
using dc, and arbitrary precision calculator program, and you
can control the number of digits of precision used for output,
etc.
Regards -- Eliot Moss
--
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: [h-e-w] cygwin-64 2.3.1. bash fails when running under FSF emacs 24.5
Dominique de Waleffe writes: > Meanwhile, I'll make a VM with a fresh install of Win10 (v1511 x64) > and just Emacs + cygwin and see whether there is something fishy about > my current setup after the upgrades it went through... Is there any reason why you don't use the Emacs that comes with Cygwin? Rebasing Cygwin won't help a bit if some of the GNUwin or MinGW (depending on the build) librraies that Emacs is compiled with collide in that same address space. 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 -- 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: [h-e-w] cygwin-64 2.3.1. bash fails when running under FSF emacs 24.5
Corinna, Thanks for the pointer. I have checked the BLODA list. The only thing I have is windows defender (part of the os:-( It can be disabled via group policy. (but I am not tempted to do that for long term) I did that but same issue... I have rebased the whole cygwin as suggested also. That did not fix the problem either. I attached the bash stack trace in case it may help. If you have any idea as to what I could do to help debug this... I'll be happy to help. Meanwhile, I'll make a VM with a fresh install of Win10 (v1511 x64) and just Emacs + cygwin and see whether there is something fishy about my current setup after the upgrades it went through... D. # Dominique de Waleffe # ddewaleffe -at- gmail -dot- com On Thu, Nov 26, 2015 at 2:51 PM, Corinna Vinschen wrote: > On Nov 25 19:38, Eli Zaretskii wrote: >> > Date: Wed, 25 Nov 2015 12:37:15 +0100 >> > From: Dominique de Waleffe >> > >> > bash: cannot set terminal process group (-1): Inappropriate ioctl for >> > device >> > bash: no job control in this shell >> > 1 [main] bash 9588 c:\s\cygwin64\bin\bash.exe: *** fatal error in forked >> > process - fork: can't reserve memory for parent stack 0x60 - 0x80, >> > (child has 0x40 - 0x60), Win32 error 487 >> > 1115 [main] bash 9588 cygwin_exception::open_stackdumpfile: Dumping stack >> > trace >> > to bash.exe.stackdump >> > 1 [main] bash 16396 fork: child -1 - forked process 9588 died unexpectedly, >> > retry 0, exit code 0x100, errno 11 >> > bash: fork: retry: No child processes >> > 1018684 [main] bash 14236 c:\s\cygwin64\bin\bash.exe: *** fatal error in >> > forked >> > process - fork: can't reserve memory for parent stack 0x60 - 0x80, >> > (child has 0x40 - 0x60), Win32 error 487 >> > 1019772 [main] bash 14236 cygwin_exception::open_stackdumpfile: Dumping >> > stack >> > trace to bash.exe.stackdump >> > 1157135 [main] bash 16396 fork: child -1 - forked process 14236 died >> > unexpectedly, retry 0, exit code 0x100, errno 11 > > https://cygwin.com/faq/faq.html#faq.using.fixing-fork-failures > >> These are Cygwin errors, which I hope Cygwin folks will be able to >> interpret. Perhaps the stack dump trace produced by this will help >> them even more, so I suggest to post its contents. > > So it looks like this is either a BLODA(*) problem, or rebasing the > entire distro is necessary(**). > > > Corinna > > > (*) https://cygwin.com/faq/faq.html#faq.using.bloda > (**) https://cygwin.com/ml/cygwin-announce/2015-02/msg00014.html > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat bash.exe.stackdump Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Rounding off real (floating point) values - bash to awk
---
> On Thu, Nov 26, 2015 at 10:29 AM, Steven Penny wrote:
> > echo 3.7 | awk '{printf "%.0f", $0}'
>
> Another option
>
> awk 'BEGIN {printf "%.0f", ARGV[1]}' 3.7
#4:
printf "%3.0f\n" 3.7
-Helmut
--
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: Rounding off real (floating point) values - bash to awk
On Thu, Nov 26, 2015 at 10:29 AM, Steven Penny wrote:
> echo 3.7 | awk '{printf "%.0f", $0}'
Another option
awk 'BEGIN {printf "%.0f", ARGV[1]}' 3.7
--
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: Rounding off real (floating point) values - bash to awk
On Thu, Nov 26, 2015 at 7:24 AM, Lester Anderson wrote:
> x=3.7
> awk -v x=$x 'BEGIN { printf "%3.0f\n", x }'
> which returns the value 4 as expected, but are there any other methods
> that can be used?
echo 3.7 | awk '{printf "%.0f", $0}'
--
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
cygwin 2.3.1: '/bin/kill -l 0' dumps core
Hi all, I have just discovered that the command '/bin/kill -l 0' dumps core where bash's built in does not (well, it just displays 'T'...). NOTE: the signal spec after dash-ell is the number zero. Pls. find the output of cygcheck and the callstack attached to this mail. Short analysis: kill.cc: main() calls listsig() with arg "0". getsig() gets called with same arg. getsig() build string "SIG0" in local buf and gives that to strtosigno() which returns 0. Then I suspect the bug in line 96 of kill.cc, the end of getsig(): if (!intsig && (strcmp (buf, "SIG0") != 0 && (strtol (in_sig, &p, 10) != 0 || *p))) intsig = -1; return intsig; intsig should be set to -1 either if intsig == 0 or if buf is not "SIG0" and strtol() returns 0 or fails, so line 96 should read if (!intsig || (strcmp (buf, "SIG0") != 0 && (strtol (in_sig, &p, 10) != 0 || *p))) This sets intsig to -1 and returns from getsig(). Without that change intsig would remain zero causing the SEGV in listsig() in line 125 where puts() is called, so another security fix in strsigno() appears to be necessary to avoid calling puts(sys_sigabbrev[0]+3); which is most likely the cause of the SEGV (I could not find the array's definition so I could not verify this). So line 125 if (signo >= 0 && signo < NSIG) should rather read if (signo > 0 && signo < NSIG) Sorry but all I can provide this a simple patch (attached) but I'm unable to test it myself. Thanks and best regards, - Michael Kwasigroch cygcheck.out Description: Binary data kill.exe.stackdump Description: Binary data kill.patch Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Rounding off real (floating point) values - bash to awk
On 11/26/2015 8:24 AM, Lester Anderson wrote:
Hello,
I can use a script like:
#!/bin/bash
x=3.7
# pass variable x to awk via -v (var=value)
awk -v x=$x 'BEGIN { printf "%3.0f\n", x }'
#
which returns the value 4 as expected, but are there any other methods
that can be used?
In bash this must be a string (bash uses only fixed width integers for numbers),
so you can put as many decimal places as you like. awk will treat it as a
string
or floating point number, depending on context. The f output format forces
conversion.
Another way is to do arithmetic; even x+0 will do it. IIRC, all numbers in
awk are
doubles (IEEE 64-bit floats). The documentation on awk can tell you more about
conversions, rounding, etc.
Regards -- Eliot Moss
--
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: [h-e-w] cygwin-64 2.3.1. bash fails when running under FSF emacs 24.5
On Nov 25 19:38, Eli Zaretskii wrote: > > Date: Wed, 25 Nov 2015 12:37:15 +0100 > > From: Dominique de Waleffe > > > > bash: cannot set terminal process group (-1): Inappropriate ioctl for device > > bash: no job control in this shell > > 1 [main] bash 9588 c:\s\cygwin64\bin\bash.exe: *** fatal error in forked > > process - fork: can't reserve memory for parent stack 0x60 - 0x80, > > (child has 0x40 - 0x60), Win32 error 487 > > 1115 [main] bash 9588 cygwin_exception::open_stackdumpfile: Dumping stack > > trace > > to bash.exe.stackdump > > 1 [main] bash 16396 fork: child -1 - forked process 9588 died unexpectedly, > > retry 0, exit code 0x100, errno 11 > > bash: fork: retry: No child processes > > 1018684 [main] bash 14236 c:\s\cygwin64\bin\bash.exe: *** fatal error in > > forked > > process - fork: can't reserve memory for parent stack 0x60 - 0x80, > > (child has 0x40 - 0x60), Win32 error 487 > > 1019772 [main] bash 14236 cygwin_exception::open_stackdumpfile: Dumping > > stack > > trace to bash.exe.stackdump > > 1157135 [main] bash 16396 fork: child -1 - forked process 14236 died > > unexpectedly, retry 0, exit code 0x100, errno 11 https://cygwin.com/faq/faq.html#faq.using.fixing-fork-failures > These are Cygwin errors, which I hope Cygwin folks will be able to > interpret. Perhaps the stack dump trace produced by this will help > them even more, so I suggest to post its contents. So it looks like this is either a BLODA(*) problem, or rebasing the entire distro is necessary(**). Corinna (*) https://cygwin.com/faq/faq.html#faq.using.bloda (**) https://cygwin.com/ml/cygwin-announce/2015-02/msg00014.html -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgps1xC5uLAnj.pgp Description: PGP signature
Re: Ability to specify /cygdrive mount value in setup
On Nov 25 21:33, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> cyg Simple sent the following at Wednesday, November 25, 2015 3:59 PM
> >>> Wed, 25 Nov 2015 19:39:08 Andrey wrote:
> >>
> >> You can precreate fstab, I think.
> >>
> >>> Yes I do this all the time. If, for example, C:\cygwin64\etc\fstab
> >>> already exists
> >>> when you run setup-x86_64.exe the first time, setup will use that
> >>> /etc/fstab.
> >>> So all the links will be created during initial installation with / and
> >>> not /cygdrive.
> >>
> >> Just which links we're talking about, yet again?...
> >>
> >
> >n 11/25/2015 3:25 PM, Andrey Repin wrote:
> >
> >find / -type l -exec ls -l {} \; | grep cygdrive
> >
> >lrwxrwxrwx 1 cyg_Simple cyg_Simple 46 Nov 25 09:29 /etc/hosts ->
> >/cygdrive/c/WINDOWS/System32/drivers/etc/hosts
> >lrwxrwxrwx 1 cyg_Simple cyg_Simple 49 Nov 25 09:29 /etc/networks ->
> >/cygdrive/c/WINDOWS/System32/drivers/etc/networks
> >lrwxrwxrwx 1 cyg_Simple cyg_Simple 49 Nov 25 09:29 /etc/protocols ->
> >/cygdrive/c/WINDOWS/System32/drivers/etc/protocol
> >lrwxrwxrwx 1 cyg_Simple cyg_Simple 49 Nov 25 09:29 /etc/services ->
> >/cygdrive/c/WINDOWS/System32/drivers/etc/services
> >
> >I also have the following which indicates that I modified /etc/fstab but
> >too late.
> >
> >lrwxrwxrwx 1 cyg_Simple cyg_Simple 0 Nov 25 15:54 /proc/cygdrive -> /
> >
> >If I were able to specify it at the start of setup this issue would not
> >be present.
>
> It look like those links are created by /etc/postinstall/base-files-mketc.sh.
> You could try just removing /etc/hosts, /etc/protocols, /etc/services, and
> /etc/networks, being careful to delete the symlink and not the target, and
> then re-run /etc/postinstall/base-files-mketc.sh.done. After modifying
> /etc/fstab, of course.
The right thing to do is to change the base-files package to utilize
/proc/cygdrive. It's a vrtual symlink pointing to the actual cygdrive
prefix currently in use. If these symlinks under /etc used the
/proc/cygdrive symlink, they would work all the time, independenly of
the actual cygdrive prefix.
Achim, any chance to tweak base-file accordingly?
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpuKExlhGExb.pgp
Description: PGP signature
Re: No support for ACLs on network shares?
On Nov 23 04:28, Matt D. wrote: > Andrey, > > My samba server is configured to use winbind and when inspecting the file > using explorer properties, the SIDs resolve correctly as: > > "NAME (HOSTNAME\username)" > > where "NAME" is my name on the unix account and "username" is my login. > > The problem is that Cygwin isn't aware of this SID since it's the user I log > in as to the remove server and isn't a local SID. I don't know why that occurs. I'd have expected to see something like UnixUser+number at least. However, the above is not the situation you use winbind for. Winbind maps Windows user accounts to Unix accounts, but in the above case it's a real Unix account, not one of the mappings used by Winbind. Your case is tricky. Windows doesn't care for the account, unless you open the security tab in the properties dialog. In that case Explorer knows the share it's looking up and so knows which server to ask for the account information. In Cygwin this works differently. Given the current flow of information, the account functions in Cygwin only get told something like "please return a passwd entry for SID S-1-x-y-z". The functions don't know in which scenario the request is performed, so it only asks the local machine for the SID, and the local machine only looks into its own SAM, or in an AD environment it's DC. If those don't know the account, Cygwin has to handle this account as unknown. ANother way to dereference an account is by utilizing the user mapping per RFC 2307 as outlined in https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-samba The method described therein allows to map the Unix account to your local Windows account, so from Cygwin's POV the files belong to your Windows user. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpcgA4VXsvKs.pgp Description: PGP signature
Rounding off real (floating point) values - bash to awk
Hello,
I can use a script like:
#!/bin/bash
x=3.7
# pass variable x to awk via -v (var=value)
awk -v x=$x 'BEGIN { printf "%3.0f\n", x }'
#
which returns the value 4 as expected, but are there any other methods
that can be used?
--
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] TEST RELEASE: Cygwin 2.4.0-0.4
Hi Kacper, On Nov 23 19:09, Kacper Michajlow wrote: > 2015-11-21 17:24 GMT+01:00 Corinna Vinschen : > > Hi Cygwin friends and users, > > > > > > I released a new TEST version of Cygwin, 2.4.0-0.4. > > > > With this version I get permissions denied when trying to chmod a > folder created in a created folder... > > Basically this doesn't work for me: > mkdir test > mkdir test/test > chmod 755 test/test I need to see the ACLs of the parent dir of test, the ACL of test and the ACL of test/test via the icacls command, before calling chmod. > Additional top level directory after creating have drwx---r-x, and > even after chmod 777, it still have only drwx---rwx. Notice no group > permissions? I might be missing something here, but doesn't look > right, does it? It is right if you're using one of those annoying Microsoft accounts instead of a real local account. If so, the primary group SID in your user token is identical to your user SID. This scenario can't be easily translated to a POSIX scenario. The group permissions are set to 0 in this case to allow security sensitive applications checking file permissions to function without complaining of too open permissions. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpnipQqqUCYF.pgp Description: PGP signature
Re: mksnt sh is invoked when executing cygwin icon;
On 26.11.2015 09:26, EXT David Macek wrote: On 26. 11. 2015 2:27, Kenneth Wolcott wrote: Hi; It seems that a 32bit Windows server with a pre-existing MKS Toolkit installation prevents an interactive Cygwin window (mintty) from starting properly. If the c:\mksnt directory (where MKS Tookkit is installed) is renamed to c:\NOTmksnt, then double-clicking the Cygwin icon results in: "Failed to run C:/mksnt/sh.exe: No such file or directory" But if the c:\NOTmksnt directory is renamed back to what it was, then the window opens up with sh.exe from mksnt instead of bash and seems to hang for a very long time. Why is this? Part of me thinks that Cygwin and MKS Toolkit should just coexist just fine, each not knowing about the other (c:\cygwin and c:\mksnt). Part of me thinks that I'd like to have Cygwin come first in the path rather than having c:\mksnt first in the path. Is there a way to force the Cygwin install process (or fix it afterward) to put Cygwin first? I tried to change /etc/profile so that the PATH variable was set to exclusively Cygwin stuff, but that had no effect. How to fix this outside Cygwin? (The Windows side) How to fix this inside Cygwin? Sounds to me like your login shell is hard-coded to C:/mksnt/sh.exe. What does `getent passwd $(whoami) | cut -d: -f7` say (run `C:\cygwin\bin\bash --login -i` directly to get a working shell)? And what does `readshortcut -a "$Desktop/Cygwin Terminal.lnk"` say? -- 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: Symlink targets dereferenced when winsymlinks:native
On Nov 24 20:51, David Macek wrote: > On 20. 11. 2015 10:26, Corinna Vinschen wrote: > > On Nov 19 22:17, David Macek wrote: > >> On 19. 11. 2015 20:36, Nellis, Kenneth wrote: > >>> FWIW, my results are different: > >>> > >>> $ printenv CYGWIN > >>> winsymlinks:nativestrict > >>> $ touch XXX > >>> $ ln -s XXX YYY > >>> $ ln -s YYY ZZZ > >>> $ ls -l > >>> total 0 > >>> -rw-r- 1 knellis Domain Users 0 Nov 19 14:28 XXX > >>> lrwxrwxrwx 1 knellis Domain Users 3 Nov 19 14:28 YYY -> XXX > >>> lrwxrwxrwx 1 knellis Domain Users 3 Nov 19 14:28 ZZZ -> YYY > >>> $ uname -svr > >>> CYGWIN_NT-6.1 2.3.1(0.291/5/3) 2015-11-14 12:44 > >>> $ > >> > >> Weird. I also tried in the virtual root directory, in case cygdrive > >> affects it, but no luck, still absolute paths. > >> > >> I'm on Windows 10, if it makes any difference. > > > > No, I'm on W10 either and it works for me as for Kenneth. The path > > evaluation in the function creating native symlinks tries to create > > relative Windows paths if the incoming target path is relative, too. > > Basically it compares the path prefixes, eliminates as much of > > the path as possible and prepends "..\\" as required. > > > > I don't see a reason why this shouldn't work for you, unless the > > shell mangles the paths before passing them to the ln command (yes, > > this really may happen with some shells depending on settings) > > It seems it's dependent on the directory after all. The shell doesn't seem to > affect it, at least not in my tests. > > My test command is `touch 1 && ln -s 1 2`, then I clean up by `rm 1 2`. Now > the results: > > in /bin/: relative > in /: absolute > in ~/ (/cygdrive/c/Users/username/): relative > in /cygdrive/w/: absolute > > Note that W: is a permasubst (created using `DOSDevices` in registry), which > would explain the different behaviour (but not excuse it :), but I don't see > why / is also special. Even if only one from the link pair (target or source) > is in a relative-symlink-unsupporting path, I get an absolute path. > > Can you confirm? Yes, thanks for this part of the analysis. There was a typo in the code checking the relative paths. The check for a drive colon in the pathname used a wrong offset into the path string, which ultimately always created an absolut path to the target if the path of the target was in a drive's root dir or one level below that. I fixed that in the repo and created a new developer snapshot for testing: https://cygwin.com/snapshots/ Please give it a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp0hbWnEf3xu.pgp Description: PGP signature
Another reason to not corrupt winnative symlinks: :currenly, they are linux-CIFS compat. Cygwin's are not.
David Macek wrote: Can you describe what purpose does your C:\proc serve? I'm not currently arguing for or against Corinna's proposal, I'm just curious. --- Notice the date on it... I created it 2-3 years ago... but it was likely to get some behavior to work the same with windows utils and linux utils. I have my cygroot set to '/' (sorta)...and paths on my linux box and windows box often resolve to the same file. Since the underlying NT OS is slash impartial, many pathnames will work w/o conversion. That's why I tried to get Corrina to support the MS-View of MS-junctions being the MS-equiv of linux Mount-points -- She's wiping out linux compatibility by turning them into the same as 'symlinkd' entries. I also had both cygwin32 and cygwin64 working on my system at the same time, with win-applications invoking the 'correct bit-wise versions and libs by using Ms's 32/64-bit 'system32' redirect, but having things like tar and rsync ovewrite your mountpoints on every install and update made it a high maintenance task. Basically my login to both machines looks very similar -- same bash setup. What was really 'cool' is mounting my win-fs near the root and having the Windows symlinks ... this is another good reason not to screw w/things... it will break linux compatibility even more... The symlinks on Windows work as unix symlinks when the share is mounted on a unix dir. So on linux, I see: l- 10 Jul 16 2013 D -> /??/UNC/Ishtar/Documents/ l- 10 Feb 28 2015 M -> /??/UNC/Bliss/Music/ l- 10 Feb 28 2015 P -> /??/UNC/Bliss/Pictures/ l- 10 Mar 28 2013 Share -> /??/UNC/Bliss/Share/ l- 10 Apr 21 2013 prog64 -> Program Files/ ===(among others)... But those links resolve on linux - I just created a dir in root named '??'.. etc. and filled out the structure... so file access on from my linux machine can resolve seemlessly. If corrina changes to a non-compatible symlink format then they won't resolve as linux symlinks under linux CIFS. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin multithreading performance
Corinna Vinschen wrote: On Nov 23 16:54, Mark Geisert wrote: John Hein wrote: Mark Geisert wrote at 23:45 -0800 on Nov 22, 2015: > Corinna Vinschen wrote: > > On Nov 21 01:21, Mark Geisert wrote: > [...] so I wonder if there's > >> some unintentional serialization going on somewhere, but I don't know yet > >> how I could verify that theory. > > > > If I'm allowed to make an educated guess, the big serializer in Cygwin > > are probably the calls to malloc, calloc, realloc, free. We desperately > > need a new malloc implementation better suited to multi-threading. [...] Someone recently mentioned on this list they were working on porting jemalloc. That would be a good choice. Indeed; thanks for the reminder. Somehow I hadn't followed that thread. Indeed^2. Did you look into the locking any further to see if there's more than one culprit? I guess we've a rather long way to a "lock-less kernel"... It took me a while to figure out what I wanted to see in the strace logs. I ended up adding a small patch to pthread_mutex::lock() to record a timestamp on entry, and also log that in the pthread_printf() near the end of the method. With that I'm able to see how long a thread has to wait for a lock before actually acquiring it. That will allow me to unravel the sequence of locking and unlocking and give stats for all threads and/or locks. That could be generally useful to evaluate different memory allocators or different locking strategies using the same allocator. But that is just groundwork to identifying which locks are suffering the most contention. To identify them at source level I think I'll also need to record the caller's RIP when they are being locked. In the raw strace data I'm looking at for the OP's testcase, I can see a lot of cases where a thread wants a lock but is delayed for milliseconds before getting ahold of it. I can't say ATM whether it's just one or a few locks suffering this way, or more. Work continues :). ..mark -- 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: [h-e-w] cygwin-64 2.3.1. bash fails when running under FSF emacs 24.5
Before upgrading another machine (still on win7/64), I updated cygwin64 on it and pulled fsfemacs 24.5 (the existing binary on gnu's site) on it... Did the same test there and on win7 it works. Could this be a Windows 10 related issue? D. PS: I'll stop cc'ing the emacs list after this message as I also think it is more likely a cygwin issue. # Dominique de Waleffe # ddewaleffe -at- gmail -dot- com On Wed, Nov 25, 2015 at 6:38 PM, Eli Zaretskii wrote: >> Date: Wed, 25 Nov 2015 12:37:15 +0100 >> From: Dominique de Waleffe >> >> bash: cannot set terminal process group (-1): Inappropriate ioctl for device >> bash: no job control in this shell >> 1 [main] bash 9588 c:\s\cygwin64\bin\bash.exe: *** fatal error in forked >> process - fork: can't reserve memory for parent stack 0x60 - 0x80, >> (child has 0x40 - 0x60), Win32 error 487 >> 1115 [main] bash 9588 cygwin_exception::open_stackdumpfile: Dumping stack >> trace >> to bash.exe.stackdump >> 1 [main] bash 16396 fork: child -1 - forked process 9588 died unexpectedly, >> retry 0, exit code 0x100, errno 11 >> bash: fork: retry: No child processes >> 1018684 [main] bash 14236 c:\s\cygwin64\bin\bash.exe: *** fatal error in >> forked >> process - fork: can't reserve memory for parent stack 0x60 - 0x80, >> (child has 0x40 - 0x60), Win32 error 487 >> 1019772 [main] bash 14236 cygwin_exception::open_stackdumpfile: Dumping stack >> trace to bash.exe.stackdump >> 1157135 [main] bash 16396 fork: child -1 - forked process 14236 died >> unexpectedly, retry 0, exit code 0x100, errno 11 > > These are Cygwin errors, which I hope Cygwin folks will be able to > interpret. Perhaps the stack dump trace produced by this will help > them even more, so I suggest to post its contents. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin multithreading performance
On Nov 23 16:54, Mark Geisert wrote: > John Hein wrote: > >Mark Geisert wrote at 23:45 -0800 on Nov 22, 2015: > > > Corinna Vinschen wrote: > > > > On Nov 21 01:21, Mark Geisert wrote: > > > [...] so I wonder if there's > > > >> some unintentional serialization going on somewhere, but I don't know > > yet > > > >> how I could verify that theory. > > > > > > > > If I'm allowed to make an educated guess, the big serializer in Cygwin > > > > are probably the calls to malloc, calloc, realloc, free. We > > desperately > > > > need a new malloc implementation better suited to multi-threading. > > > > > > That's very helpful to know. I'd want to first make sure the heavy lock > > > activity I'm seeing in the traces really is due to malloc() and friends > > > but I couldn't help a speculative search online for multithread-safe > > > malloc(). These turned up: > > > tcmalloc - part of google-perftools, requires libunwind, evidently > > > not yet ported to Windows AFAICT, > > > nedmalloc - http://www.nedprod.com/programs/portable/nedmalloc/ > > > ptmalloc - http://www.malloc.de/ > > > > > > The latter two are based on Doug Lea's dlmalloc which is also the basis > > > of Cygwin's malloc() functions. As I understand it, ptmalloc in one > > > form or another has been part of glibc on Linux for some time. > > > > > > So there may be a solution in sight if we need to go that direction. Of > > > course, SHTDI as usual :). > > > > > > ...mark > > > >Someone recently mentioned on this list they were working on porting > >jemalloc. That would be a good choice. > > Indeed; thanks for the reminder. Somehow I hadn't followed that thread. Indeed^2. Did you look into the locking any further to see if there's more than one culprit? I guess we've a rather long way to a "lock-less kernel"... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpKdSWOfI5w1.pgp Description: PGP signature
Re: Jemalloc under CYGWIN
Hi Yucong Sun, On Oct 21 17:40, Corinna Vinschen wrote: > On Oct 21 22:43, Yucong Sun wrote: > > On Wed, Oct 21, 2015 at 10:15 PM, Corinna Vinschen > > wrote: > > > On Oct 21 21:49, Yucong Sun wrote: > > >> > What exactly is the malloc problem you're seeing? > > >> > > >> The specific problem I'm having is that jemalloc's malloc_init() calls > > >> needs to use pthread_mutex_init() or even pthread_mutex with a > > >> initializer. Both in-turn uses malloc, triggering this issue. > > >> > > >> A quick fix would be somehow make pthread always use system > > >> malloc/free, which shouldn't be that bad. > > > > > > What about using a native critical section instead? It shouldn't be too > > > tricky to conditionalize this in jemalloc. > > > > Possibly, jemalloc already have support of this. However I wasn't so > > sure that this was possible before, > > > > see > > https://github.com/jemalloc/jemalloc/blob/dev/include/jemalloc/internal/mutex.h#L80 > > Yes, that looks good. Please use critical sections for the time being. > We're going to drop XP support end of this year, but up to that point we > can't use SRW locks. did you manage to include jemalloc into Cygwin in the meantime? It would be very cool to get a patch to replace dlmalloc with jemalloc :} Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpgHLXHstKuH.pgp Description: PGP signature
Re: mksnt sh is invoked when executing cygwin icon;
On 26. 11. 2015 2:27, Kenneth Wolcott wrote: > Hi; > > It seems that a 32bit Windows server with a pre-existing MKS Toolkit > installation prevents an interactive Cygwin window (mintty) from > starting properly. > > If the c:\mksnt directory (where MKS Tookkit is installed) is > renamed to c:\NOTmksnt, then double-clicking the Cygwin icon results > in: > > "Failed to run C:/mksnt/sh.exe: No such file or directory" > > But if the c:\NOTmksnt directory is renamed back to what it was, then > the window opens up with sh.exe from mksnt instead of bash and seems > to hang for a very long time. > >Why is this? Part of me thinks that Cygwin and MKS Toolkit should > just coexist just fine, each not knowing about the other (c:\cygwin > and c:\mksnt). Part of me thinks that I'd like to have Cygwin come > first in the path rather than having c:\mksnt first in the path. Is > there a way to force the Cygwin install process (or fix it afterward) > to put Cygwin first? > > I tried to change /etc/profile so that the PATH variable was set to > exclusively Cygwin stuff, but that had no effect. > > How to fix this outside Cygwin? (The Windows side) > > How to fix this inside Cygwin? Sounds to me like your login shell is hard-coded to C:/mksnt/sh.exe. What does `getent passwd $(whoami) | cut -d: -f7` say (run `C:\cygwin\bin\bash --login -i` directly to get a working shell)? -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
