jq bug report: jq errors trigger assertion errors rather than being handled

Hi, I'm seeing consistent behaviour when running `jq` on Cygwin, where commands that should trigger jq to produce an error message instead cause it to assert and die. Simple test case: run `jq -n 'error("oh no!")'`, which should raise a jq error with the text "oh no!". Output on Cygwin: $

Re: bug report

On 2023-09-06 16:20, Asad Ali via Cygwin wrote: On Fri, Dec 30, 2022 at 5:46 AM Asad Ali wrote: I'm a penetration tester and bug bounty hunter. I have found a potential vulnerability in the site. Please review the report below. Is there any update on this ? I'm hoping to receive a reward for

Re: bug report

Hi Team, Is there any update on this ? I'm hoping to receive a reward for the reported bug. Waiting for your response. On Fri, Dec 30, 2022 at 5:46 AM Asad Ali wrote: > Hey Team, > > > > I'm a penetration tester and bug bounty hunter. I have found a potential > vulnerability in the site.

Re: Bug report for cygwin X server (or xterm)

Am 10.03.2022 um 10:37 schrieb n952162: xterm*VT100.Translations only when mouse is over the window with focus Discovered with click-to-focus, in FVWM In particular, I'm talking about the function keys. In this case, these are NOT mapped in fvwm, but in xterm. Pressing a function key, like

Bug report for cygwin X server (or xterm)

xterm*VT100.Translations only when mouse is over the window with focus Discovered with click-to-focus, in FVWM In particular, I'm talking about the function keys. In this case, these are NOT mapped in fvwm, but in xterm. Pressing a function key, like F1, always writes to the window with focus,

Re: Bug Report

On Tue, Feb 8, 2022 at 3:02 PM julie77793 wrote: Cygwin doesn't create an environment variable in bash to indicate that the > platform is Cygwin under Windows. > FYI, as a point of decorum: The subject line of this thread is rather undiplomatic. (Bug usually means "software should do X but

Re: Bug Report

On 2/8/22 2:01 PM, julie77...@gmail.com wrote: Cygwin doesn't create an environment variable in bash to indicate that the platform is Cygwin under Windows. This causes compatibility problems when running various tools. Most of my issues have been with Python tools running Windows Python. I

RE: [EXTERNAL] Bug Report

> Please add some way of identifying that programs are running under Cygwin. Have you tried to use the "uname" command for the identification purposes? $ uname CYGWIN_NT-6.1 $ uname CYGWIN_NT-10.0 Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports:

Bug Report

Cygwin doesn't create an environment variable in bash to indicate that the platform is Cygwin under Windows. This causes compatibility problems when running various tools. Most of my issues have been with Python tools running Windows Python. I have been addressing this issue by grepping PATH for

Re: BUG Report (SOLVED): rlwrap + cygwin (dll) + Windows 10

Hi, everybody First of all, this is my first bug report, so I don't know if I am doing correctly... I don't know if one must be registered to summit this type of repport. And be patient with my English. The problem is that rlwrap has stopped working in combination with: - Windows 10 (

Re: BUG Report: rlwrap + cygwin (dll) + Windows 10

On 12/13/2020 9:41 AM, Marco Atzeri via Cygwin wrote: On 13.12.2020 13:43, Takashi Yano via Cygwin wrote: On Sat, 12 Dec 2020 20:05:05 + (UTC) Alberto Moral Beneitez via Cygwin  wrote: Hi, everybody Please try: env CYGWIN=disable_pcon rlwrap cmd Also, you can use alias like: alias

Re: BUG Report: rlwrap + cygwin (dll) + Windows 10

On 13.12.2020 13:43, Takashi Yano via Cygwin wrote: On Sat, 12 Dec 2020 20:05:05 + (UTC) Alberto Moral Beneitez via Cygwin wrote: Hi, everybody Please try: env CYGWIN=disable_pcon rlwrap cmd Also, you can use alias like: alias rlwrap="env CYGWIN=disable_pcon rlwrap" I had the

Re: BUG Report: rlwrap + cygwin (dll) + Windows 10

On Sat, 12 Dec 2020 20:05:05 + (UTC) Alberto Moral Beneitez via Cygwin wrote: > Hi, everybody > First of all, this is my first bug report, so I don't know if I am doing > correctly... I don't know if one must be registered to summit this type of > repport. And be patient wit

BUG Report: rlwrap + cygwin (dll) + Windows 10

Hi, everybody First of all, this is my first bug report, so I don't know if I am doing correctly... I don't know if one must be registered to summit this type of repport. And be patient with my English. The problem is that rlwrap has stopped working in combination with: - Windows 10 (I

bug report: tty/termios flags weirdness

After thrashing with my own bugs for a while, I think I've found a minor bug in Cygwin's tty/termios handling-- seen in 3.1.7 on Windows 10 20H2.  Among other things, this causes tmux to fail on non-pty sessions. STC: Start Cygwin in conhost or Windows Terminal. Execute 'stty -isig' You will

Re: bug report: shell expansion in argv[] processing sensitive to LANG, e.g. "ls: cannot access '*.pdf': No such file or directory", but works okay in bash

On 2020/04/02 06:43, Andrey Repin wrote: That's not what actually happens. ...\Documents> ls -1 *.pdf 21927-ticket.pdf 'Stars! Universe Map.pdf' --- Thank you for your update. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/

Re: bug report: shell expansion in argv[] processing sensitive to LANG, e.g. "ls: cannot access '*.pdf': No such file or directory", but works okay in bash

Greetings, L A Walsh! > On 2020/03/24 00:18, Jay Libove via Cygwin wrote: >> Problem: >> Under certain circumstances (see Steps to Reproduce, below) Cygwin programs' >> built-in argv[] globbing will produce unexpected: >> "{programName}: cannot access '{glob pattern}: No such file or directory"

Re: bug report: shell expansion in argv[] processing sensitive to LANG, e.g. "ls: cannot access '*.pdf': No such file or directory", but works okay in bash

On 2020/03/24 00:18, Jay Libove via Cygwin wrote: Problem: Under certain circumstances (see Steps to Reproduce, below) Cygwin programs' built-in argv[] globbing will produce unexpected: "{programName}: cannot access '{glob pattern}: No such file or directory" e.g. "ls: cannot access '*.pdf': No

Re: bug report: shell expansion in argv[] processing sensitive to LANG, e.g. "ls: cannot access '*.pdf': No such file or directory", but works okay in bash

Maybe it can simply be fixed by changing the order of setting up locale stuff and applying the expansion in cygwin? (I would look into the code if I had a clue where to find the respective things.) I would guess dcrt0.cc, the Cygwin DLL runtime initialization. ..mark -- Problem reports:

Re: bug report: shell expansion in argv[] processing sensitive to LANG, e.g. "ls: cannot access '*.pdf': No such file or directory", but works okay in bash

Am 24.03.2020 um 08:18 schrieb Jay Libove via Cygwin: Hi Cygwin team, Here is a consolidated bug report based on the discussion in recent days which I'd started under the subject " shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Wi

bug report: shell expansion in argv[] processing sensitive to LANG, e.g. "ls: cannot access '*.pdf': No such file or directory", but works okay in bash

Hi Cygwin team, Here is a consolidated bug report based on the discussion in recent days which I'd started under the subject " shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash " (thread starter

Re: Bug report: Killing a native process may not actually kill it

On Thu, 29 Aug 2019, 02:38 Steven Penny, wrote: > On Wed, 28 Aug 2019 15:57:23, Quanah Gibson-Mount wrote: > > My original post contained a link to a patch allowing for Cygwin to > > correctly terminate native Windows processes. I understand it is not > the > > position of the Cygwin project to

Re: Bug report: Killing a native process may not actually kill it

On Wed, 28 Aug 2019 15:57:23, Quanah Gibson-Mount wrote: My original post contained a link to a patch allowing for Cygwin to correctly terminate native Windows processes. I understand it is not the position of the Cygwin project to deal with situation, so I think we can just let it drop. I

Re: Bug report: Killing a native process may not actually kill it

--On Wednesday, August 28, 2019 2:33 PM -0700 Kaz Kylheku <920-082-4...@kylheku.com> wrote: Cygwin can't introduce Unix-like shutdown mechanisms (like the handling a non-fatal signal) into non-Cygwin processes which have no concept of that. It makes no sense. My original post contained a

Re: Bug report: Killing a native process may not actually kill it

On 2019-08-28 08:59, Quanah Gibson-Mount wrote: --On Wednesday, August 28, 2019 6:45 PM +0200 Corinna Vinschen wrote: Not likely. Cygwin handles Ctrl-C by generating SIGINT. This only works reliably with Cygwin processes. There's $ /bin/kill -f to call the Win32 function

Re: Bug report: Killing a native process may not actually kill it

On Aug 28 08:59, Quanah Gibson-Mount wrote: > > > --On Wednesday, August 28, 2019 6:45 PM +0200 Corinna Vinschen > wrote: > > > Not likely. Cygwin handles Ctrl-C by generating SIGINT. This only > > works reliably with Cygwin processes. There's > > > > $ /bin/kill -f > > > > to call the

Re: Bug report: Killing a native process may not actually kill it

--On Wednesday, August 28, 2019 6:45 PM +0200 Corinna Vinschen wrote: Not likely. Cygwin handles Ctrl-C by generating SIGINT. This only works reliably with Cygwin processes. There's $ /bin/kill -f to call the Win32 function TerminateProcess(pid) on a non-Cygwin process or an

Re: Bug report: Killing a native process may not actually kill it

On Aug 28 08:18, Quanah Gibson-Mount wrote: > > > --On Thursday, July 25, 2019 11:32 AM -0700 Quanah Gibson-Mount > wrote: > > > As found and reported to the MSYS team back in 2006 by Howard Chu, if a > > native process is spawned, control-C, the kill command, etc, may not > > actually kill

Re: Bug report: Killing a native process may not actually kill it

--On Thursday, July 25, 2019 11:32 AM -0700 Quanah Gibson-Mount wrote: As found and reported to the MSYS team back in 2006 by Howard Chu, if a native process is spawned, control-C, the kill command, etc, may not actually kill the process. Details are here: I haven't seen a reply to

openldap on Cygwin (was: Bug report: Killing a native process may not actually kill it)

Quanah Gibson-Mount writes: […] Sorry for wedging in sideways, but I've looked into building a more up-to-date openldap and there's missing detection / configuration for Cygwin. Specifically, there's code trying to use robust POSIX mutexes, which Cygwin doesn't have. As there is no configure

Bug report: Killing a native process may not actually kill it

As found and reported to the MSYS team back in 2006 by Howard Chu, if a native process is spawned, control-C, the kill command, etc, may not actually kill the process. Details are here: as well as here:

Re: Bug report. Clang sqrtl(-1) causes access violation

On May 10 14:57, Agner Fog wrote: > Bug description: > > The sqrtl function under Clang causes an access violation when the argument > is negative. > > This error occurs only under Cygwin. > > This error occurs only with the sqrtl function, not with sqrt or sqrtf > > Attached: > > sqrt.cpp:

Re: Bug report. Clang sqrtl(-1) causes access violation

Agner Fog, on Friday, May 10, 2019 04:55 PM, wrote... >$ uname -a >CYGWIN_NT-10.0 DESKTOP-08PNUTF 3.0.6(0.338/5/3) 2019-04-06 16:18 x86_64 >Cygwin > > >$ clang --version >clang version 5.0.1 (tags/RELEASE_501/final) >Target: x86_64-unknown-windows-cygnus >Thread model: posix >InstalledDir:

Re: Bug report. Clang sqrtl(-1) causes access violation

$ uname -a CYGWIN_NT-10.0 DESKTOP-08PNUTF 3.0.6(0.338/5/3) 2019-04-06 16:18 x86_64 Cygwin $ clang --version clang version 5.0.1 (tags/RELEASE_501/final) Target: x86_64-unknown-windows-cygnus Thread model: posix InstalledDir: /usr/bin On 10/05/2019 21.54, Jose Isaias Cabrera wrote: Agner

Re: Bug report. Clang sqrtl(-1) causes access violation

Agner Fog, on Friday, May 10, 2019 03:44 PM, wrote... > >On 10/05/2019 15.50, Jose Isaias Cabrera wrote: > >> It works for me. > >Now it turns out that all the long double math functions cause access >violations. > >If you can't reproduce the error, what can I do to trace it? > > >Exception:

Re: Bug report. Clang sqrtl(-1) causes access violation

On 10/05/2019 15.50, Jose Isaias Cabrera wrote: It works for me. Now it turns out that all the long double math functions cause access violations. If you can't reproduce the error, what can I do to trace it? Exception: STATUS_ACCESS_VIOLATION at rip=00180173164 Sam Habiel wrote: Wow

Re: Bug report. Clang sqrtl(-1) causes access violation

Am 10.05.2019 um 15:38 schrieb Sam Habiel: > Wow I can't believe that The Agner Fog posted on the Cygwin mailing list! > > https://www.agner.org/ > > On Fri, May 10, 2019 at 8:58 AM Agner Fog wrote: >> >> Bug description: >> >> The sqrtl function under Clang causes an access violation when the

Re: Bug report. Clang sqrtl(-1) causes access violation

Agner Fog, on Friday, May 10, 2019 08:57 AM, wrote... > >Bug description: > >The sqrtl function under Clang causes an access violation when the >argument is negative. > >This error occurs only under Cygwin. > >This error occurs only with the sqrtl function, not with sqrt or sqrtf > It works for

Re: Bug report. Clang sqrtl(-1) causes access violation

Wow I can't believe that The Agner Fog posted on the Cygwin mailing list! https://www.agner.org/ On Fri, May 10, 2019 at 8:58 AM Agner Fog wrote: > > Bug description: > > The sqrtl function under Clang causes an access violation when the > argument is negative. > > This error occurs only under

Bug report. Clang sqrtl(-1) causes access violation

Bug description: The sqrtl function under Clang causes an access violation when the argument is negative. This error occurs only under Cygwin. This error occurs only with the sqrtl function, not with sqrt or sqrtf Attached: sqrt.cpp: program to reproduce the error. Compile clang sqrt.cpp

Re: Bug report: Core dump with too many args

Ole Tange writes: > I get core dump when running: > > $ /bin/echo `seq 100` > Segmentation fault (core dumped) > > This also looks bad: > > $ /bin/wc `seq 100` > 2 [main] -bash 15396 C:\cygwin\bin\bash.exe: *** fatal error - cmalloc > would have returned NULL > Hangup They both

Re: Bug report: Core dump with too many args

On Wed, 7 Nov 2018 13:37:53, Ole Tange wrote: I get core dump when running: $ /bin/echo `seq 100` Segmentation fault (core dumped) This also looks bad: $ /bin/wc `seq 100` 2 [main] -bash 15396 C:\cygwin\bin\bash.exe: *** fatal error - cmallo= c would have returned NULL Hangup

Bug report: Core dump with too many args

I get core dump when running: $ /bin/echo `seq 100` Segmentation fault (core dumped) This also looks bad: $ /bin/wc `seq 100` 2 [main] -bash 15396 C:\cygwin\bin\bash.exe: *** fatal error - cmalloc would have returned NULL Hangup Versions: $ bash --version GNU bash, version

Re: Bug Report: Regression in Cygwin 2.11.0-1

On Sep 3 21:12, Achim Gratz wrote: > Corinna Vinschen writes: > >> How feasible would it be to generate an alternate setup.ini > >> (setup-snapshots.ini or something) and include the snapshots in the > >> actual mirror with a switch to setup to select the alternate file? > >> When we finally get

Re: Bug Report: Regression in Cygwin 2.11.0-1

Corinna Vinschen writes: >> How feasible would it be to generate an alternate setup.ini >> (setup-snapshots.ini or something) and include the snapshots in the >> actual mirror with a switch to setup to select the alternate file? >> When we finally get to it with OCaml's CI, that is probably how I

Re: Bug Report: Regression in Cygwin 2.11.0-1

On Sep 2 08:37, David Allsopp wrote: > Corinna Vinschen wrote: > > On Sep 1 16:41, David Allsopp wrote: > > > Corinna Vinschen wrote: > > > > Some of the path handling is seriously crippled as soon as you start > > > > using backslashes, and that's a delipberate decision and won't > > > >

RE: Bug Report: Regression in Cygwin 2.11.0-1

Corinna Vinschen wrote: > On Sep 1 16:41, David Allsopp wrote: > > Corinna Vinschen wrote: > > > Some of the path handling is seriously crippled as soon as you start > > > using backslashes, and that's a delipberate decision and won't > > > change, even after fixing the aforementioned bug. > > >

RE: Bug Report: Regression in Cygwin 2.11.0-1

cyg Simple wrote: > On 9/1/2018 5:52 PM, Andrey Repin wrote: > > Greetings, David Allsopp! > > > >>> In terms of this OCAML build system problem: > >>> > >>> Please fix your build system. Do not mix POSIX and Win32 paths, use > >>> POSIX paths only. Backslashes are *no* drop-in replacement for

Re: Bug Report: Regression in Cygwin 2.11.0-1

On 9/1/2018 5:52 PM, Andrey Repin wrote: > Greetings, David Allsopp! > >>> In terms of this OCAML build system problem: >>> >>> Please fix your build system. Do not mix POSIX and Win32 paths, use POSIX >>> paths only. Backslashes are *no* drop-in replacement for slashes. > >> The "problem" for

Re: Bug Report: Regression in Cygwin 2.11.0-1

Greetings, David Allsopp! >> In terms of this OCAML build system problem: >> >> Please fix your build system. Do not mix POSIX and Win32 paths, use POSIX >> paths only. Backslashes are *no* drop-in replacement for slashes. > The "problem" for us is more subtle than this. The program which is

Re: Bug Report: Regression in Cygwin 2.11.0-1

On Sat, 1 Sep 2018 21:23:56, Corinna Vinschen wrote: > > Yes, you would run the chance that you would have to mend an official > > release several times ... but is that bad? > > The idea of test releases is to avoid problem like the one we're discussing > here in official releases. I'd like to

Re: Bug Report: Regression in Cygwin 2.11.0-1

> As for the bug in question: I pushed a patch which should fix this > issue. I created new developer snapshots and uploaded them to > https://cygwin.com/snapshots/. Please give them a try. Thank you Corinna for the quick fix and investigation! I set up an environment to test it out:

Re: Bug Report: Regression in Cygwin 2.11.0-1

On Sep 1 20:08, Houder wrote: > On Sat, 1 Sep 2018 17:54:35, Corinna Vinschen wrote: > > I'll fix this and release a 2.11.1 soon, but I still have a question: > > > > Why do I push out test releases if nobody cares? > > Yes, I know, it is a _hypothetical_question_. You do not really expect > an

Re: Bug Report: Regression in Cygwin 2.11.0-1

On Sep 1 16:41, David Allsopp wrote: > Corinna Vinschen wrote: > > Some of the path handling is seriously crippled as soon as you start using > > backslashes, and that's a delipberate decision and won't change, even after > > fixing the aforementioned bug. > > I don't quite follow this - does

Re: Bug Report: Regression in Cygwin 2.11.0-1

On Sat, 1 Sep 2018 17:54:35, Corinna Vinschen wrote: > I'll fix this and release a 2.11.1 soon, but I still have a question: > > Why do I push out test releases if nobody cares? Yes, I know, it is a _hypothetical_question_. You do not really expect an answer. However it was my thought exactly.

RE: Bug Report: Regression in Cygwin 2.11.0-1

Corinna Vinschen wrote: > On Sep 1 09:56, Andreas Hauptmann wrote: > > On Sat, 1 Sep 2018 01:24:49 + > > Bryan Phelps wrote: > > > > > I'll continue to look around for a more minimal repro, > > > > The normalization of paths with backslashes has changed. > > > > The following doesn't work any

Re: Bug Report: Regression in Cygwin 2.11.0-1

On Sep 1 09:56, Andreas Hauptmann wrote: > On Sat, 1 Sep 2018 01:24:49 + > Bryan Phelps wrote: > > > I'll continue to look around for a more minimal repro, > > The normalization of paths with backslashes has changed. > > The following doesn't work any longer: > > cd /tmp > stat

Re: Bug Report: Regression in Cygwin 2.11.0-1

Am 01.09.2018 um 10:10 schrieb Marco Atzeri: Am 01.09.2018 um 03:24 schrieb Bryan Phelps: Hello, Thank you for all the work on Cygwin! I've been using it to spin up an environment to build the OCaml compiler / toolchain, and it was working great. However, today, all our CI builds

RE: Bug Report: Regression in Cygwin 2.11.0-1

Marco Atzeri wrote: > Am 01.09.2018 um 03:24 schrieb Bryan Phelps: > > Hello, > > > > > > Thank you for all the work on Cygwin! I've been using it to spin up an > environment to build the OCaml compiler / toolchain, and it was working great. > > > > > > However, today, all our CI builds

Re: Bug Report: Regression in Cygwin 2.11.0-1

Am 01.09.2018 um 03:24 schrieb Bryan Phelps: Hello, Thank you for all the work on Cygwin! I've been using it to spin up an environment to build the OCaml compiler / toolchain, and it was working great. However, today, all our CI builds mysteriously started failing - at first, I suspected

Re: Bug Report: Regression in Cygwin 2.11.0-1

Am 01.09.2018 um 03:24 schrieb Bryan Phelps: Hello, In the meantime - is there a way we can pin the cygwin package to the 2.10.0-1 version, to unblock our builds? Thank you! Bryan What is the problem in installing the previous version of the package ? --- Diese E-Mail wurde von Avast

Re: Bug Report: Regression in Cygwin 2.11.0-1

On Sat, 1 Sep 2018 01:24:49 + Bryan Phelps wrote: > I'll continue to look around for a more minimal repro, The normalization of paths with backslashes has changed. The following doesn't work any longer: cd /tmp stat "..\bin\file.exe" # or stat "..\\bin\\file.exe" This however

Bug Report: Regression in Cygwin 2.11.0-1

Hello, Thank you for all the work on Cygwin! I've been using it to spin up an environment to build the OCaml compiler / toolchain, and it was working great. However, today, all our CI builds mysteriously started failing - at first, I suspected it was a problem with AppVeyor, but I also

Re: I sent in a bug report and never heard anything back

jeff writes: > You are correct. The gcc people replied to my bug report with: > > "So the problem is your GMP/MPFR are compiled for one type of CPU and cannot > be > copied to other type." > > They closed it as a resolved issue. Correct, since it's not their bug

Re: I sent in a bug report and never heard anything back

replied to my bug report with: "So the problem is your GMP/MPFR are compiled for one type of CPU and cannot be copied to other type." They closed it as a resolved issue. So the problem is that gcc now requires GMP, and GMP was compiled with options that are not compatible with my CPU.

Re: I sent in a bug report and never heard anything back

On 2016-08-27 10:27, jeff wrote: Brian Inglis wrote: Apparently it's a mobile Broadwell without AVX or AVX2, which might be assumed present in gcc as compiled, requiring a custom gcc build to run on that cpu. My reply: You are correct. The gcc people replied to my bug report with: &qu

Re: I sent in a bug report and never heard anything back

Brian Inglis wrote: Apparently it's a mobile Broadwell without AVX or AVX2, which might be assumed present in gcc as compiled, requiring a custom gcc build to run on that cpu. My reply: You are correct. The gcc people replied to my bug report with: "So the problem is your GMP/MPFR are com

Re: I sent in a bug report and never heard anything back

for the cygwin people to address it. Since I sent the bug report in Aug 1, and I have gotten no useful response from cygwin, I will be reporting the issue directly to the gcc folks. jeff -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation

Re: I sent in a bug report and never heard anything back

On 2016-08-26 11:55, Hans-Bernhard Bröker wrote: Am 26.08.2016 um 16:30 schrieb j...@jeffunit.com: The issue is the internal compiler error coming from gcc on my dell with a specific intel processor. I don't remember you telling one the specifics of that specific processor, yet. Apparently

Re: I sent in a bug report and never heard anything back

Am 26.08.2016 um 16:30 schrieb j...@jeffunit.com: The issue is the internal compiler error coming from gcc on my dell with a specific intel processor. I don't remember you telling one the specifics of that specific processor, yet. it means the compiler has a bug (which I suspect is

Re: I sent in a bug report and never heard anything back

on an older xeon and amd processors. Enclosed is the output of cygcheck. Here is what happens when I try to compile: sh-4.3$ gcc bug_f2.c bug_f2.c: In function 'Round': bug_f2.c:23:5: internal compiler error: Illegal instruction return floor(d + 0.5); ^ Please submit a full bug report

Re: I sent in a bug report and never heard anything back

is the output of cygcheck. Here is what happens when I try to compile: sh-4.3$ gcc bug_f2.c bug_f2.c: In function 'Round': bug_f2.c:23:5: internal compiler error: Illegal instruction return floor(d + 0.5); ^ Please submit a full bug report, with preprocessed source if appropriate. See <h

Re: I sent in a bug report and never heard anything back

On 16/08/2016 18:07, j...@jeffunit.com wrote: I sent in http://sourceware.org/ml/cygwin/2016-08/msg0.html about an internal compiler error with gcc. It has been about 2 weeks and I have gotten no reply. It would be nice to fix this bug. thanks, jeff the code compile on both 32bit and 64

I sent in a bug report and never heard anything back

I sent in http://sourceware.org/ml/cygwin/2016-08/msg0.html about an internal compiler error with gcc. It has been about 2 weeks and I have gotten no reply. It would be nice to fix this bug. thanks, jeff -- Problem reports: http://cygwin.com/problems.html FAQ:

Re: Cygwin IPC - ftok() returns negative values - Bug Report

On Jun 29 20:13, Stanisław Wawszczak wrote: > > > > Do you have the cygserver service running? (See > > /usr/share/doc/Cygwin/cygserver.README.) > > > > Ken > Yes, I have. And I have believed that defaults are as stated in config file, > but they aren't. > Just after uncommenting the >

RE: Cygwin IPC - ftok() returns negative values - Bug Report

> > Do you have the cygserver service running? (See > /usr/share/doc/Cygwin/cygserver.README.) > > Ken Yes, I have. And I have believed that defaults are as stated in config file, but they aren't. Just after uncommenting the kern.ipc.semmsl 60 config line and restarting the cygserver it

Re: Cygwin IPC - ftok() returns negative values - Bug Report

On 6/29/2016 3:20 PM, Stanisław Wawszczak wrote: On 29/06/2016 18:06, Stanisław Wawszczak wrote: *Real question is why Cygwin's implementation of getsem() is not allowing to ask for more than nsems == 1?* Here is stated, that the platform is limiting the nsems value:

RE: Cygwin IPC - ftok() returns negative values - Bug Report

>On 29/06/2016 18:06, Stanisław Wawszczak wrote: >> Dear Corinna, >> >> I am sorry about confusing you. >> Simply: >> >> - Issue >> >> Call to ftok() returns negative value > > Hi Stanisław, > > may be I am missing somthing, but

Re: Cygwin IPC - ftok() returns negative values - Bug Report

On 29/06/2016 18:06, Stanisław Wawszczak wrote: Dear Corinna, I am sorry about confusing you. Simply: - Issue Call to ftok() returns negative value Hi Stanisław, may be I am missing somthing, but nothing on

RE: Cygwin IPC - ftok() returns negative values - Bug Report

nna Vinschen Sent: Wednesday, June 29, 2016 5:15 PM To: cygwin@cygwin.com Subject: Re: Cygwin IPC - ftok() returns negative values - Bug Report On Jun 29 13:14, Stanisław Wawszczak wrote: > Dear All, >   > I have had to compile sblim-sfcbd-1.4.10 on Cygwin. It is using IPC > semaphores

Re: Cygwin IPC - ftok() returns negative values - Bug Report

On Jun 29 13:14, Stanisław Wawszczak wrote: > Dear All, >   > I have had to compile sblim-sfcbd-1.4.10 on Cygwin. It is using IPC > semaphores. > Unfortunately it is returning wrong value as the result of complicated > bit-wise logical operations. > I have tried to “hack the system” and make

Cygwin IPC - ftok() returns negative values - Bug Report

Dear All,   I have had to compile sblim-sfcbd-1.4.10 on Cygwin. It is using IPC semaphores. Unfortunately it is returning wrong value as the result of complicated bit-wise logical operations. I have tried to “hack the system” and make multiplication of returned value by -1, but it triggers error

Bug report, but already fixed in TEST RELEASE: Cygwin 2.5.0-0.7

I delete all cygwin directories and do a Fresh minimal install of cygwin (2.4.1-1) on a windows 7 ultimate 64 bit box davec@MERCURYWIN ~ $ cd python davec@MERCURYWIN ~/python $ rm -rf g1 davec@MERCURYWIN ~/python $ mkdir g1 g1/g2 g1/g2/g3 davec@MERCURYWIN ~/python $ ls -la g1 g1/g2 g1/g2/g3

Re: Bug Report on Patcher for KSP

On Nov 14 22:22, Ian Hawkins wrote: 1 [main] rsync 1176 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to Old Cygwin version, please update. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer

Fwd: Bug Report on Patcher for KSP

-- Forwarded message -- From: Ian Hawkins afirdar...@gmail.com Date: Fri, Nov 14, 2014 at 10:15 PM Subject: Bug Report on Patcher for KSP To: cygwin@cygwin.com 1 [main] rsync 1176 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public

Re: Bug report: 1.7.19 broke floppy drive access

On May 20 16:41, Sean Gugler wrote: Confirmed fixed, Corinna. Awesome! Thank you! ~ Sean On Tue, 20 May 2014 12:39:20 +0200, Corinna Vinschen wrote: On May 19 15:28, Sean Gugler wrote: Greetings, I've discovered that 5.25 and 3.5 floppy drive access became broken as of Cygwin1.dll

Re: Bug report: 1.7.19 broke floppy drive access

On May 19 15:28, Sean Gugler wrote: Greetings, I've discovered that 5.25 and 3.5 floppy drive access became broken as of Cygwin1.dll version 1.7.19-1 (2013-06-05 01:07:23). I reported this back in October, but perhaps the message never got through. The problem persists with the latest

Re: Bug report: 1.7.19 broke floppy drive access

Confirmed fixed, Corinna. Awesome! Thank you! ~ Sean On Tue, 20 May 2014 12:39:20 +0200, Corinna Vinschen wrote: On May 19 15:28, Sean Gugler wrote: Greetings, I've discovered that 5.25 and 3.5 floppy drive access became broken as of Cygwin1.dll version 1.7.19-1 (2013-06-05 01:07:23). I

Bug report: 1.7.19 broke floppy drive access

Greetings, I've discovered that 5.25 and 3.5 floppy drive access became broken as of Cygwin1.dll version 1.7.19-1 (2013-06-05 01:07:23). I reported this back in October, but perhaps the message never got through. The problem persists with the latest version. I tested by updating all my packages

Re: bug report: 64-bit cygwin setup crashes under Wine

On Thursday, September 05, 2013 at 4:28 AM, Warren Young wrote: I purposefully said and licensing though, because the Windows license swamps the hardware costs. It can be true about the SSD and RAM costs but it's not the same kind of sandbox too (Wine vs VM). But about the licensing costs I

Re: bug report: 64-bit cygwin setup crashes under Wine

On 04/09/2013 7:09 PM, Christopher Faylor wrote: On Wed, Sep 04, 2013 at 03:26:10PM -0600, Warren Young wrote: This bug could well be Wine's, rather than Cygwin's. Wine can always play the It's not documented to work that way card but the bottom line is still that it is not a platform that we

RE: bug report: 64-bit cygwin setup crashes under Wine

Am I missing something, or is there a reason one would want to run a Linux emulator under a Windows emulator on Linux?

Re: bug report: 64-bit cygwin setup crashes under Wine

On Wed, Sep 04, 2013 at 03:36:46PM +, Jim Garrison wrote: Am I missing something, or is there a reason one would want to run a Linux emulator under a Windows emulator on Linux? That is the question I've been asking for years. Someone always has an answer but I'm never been convinced that it

Re: bug report: 64-bit cygwin setup crashes under Wine

On 9/4/2013 09:36, Jim Garrison wrote: Am I missing something, or is there a reason one would want to run a Linux emulator under a Windows emulator on Linux? For myself, it is occasionally nice to have a Cygwin sandbox environment to play with when I'm on one of my Macs, away from a Windows

Re: bug report: 64-bit cygwin setup crashes under Wine

On Wed, Sep 4, 2013 at 5:26 PM, Warren Young wrote: On 9/4/2013 09:36, Jim Garrison wrote: Am I missing something, or is there a reason one would want to run a Linux emulator under a Windows emulator on Linux? For myself, it is occasionally nice to have a Cygwin sandbox environment to play

Re: bug report: 64-bit cygwin setup crashes under Wine

On Wed, Sep 04, 2013 at 03:26:10PM -0600, Warren Young wrote: This bug could well be Wine's, rather than Cygwin's. Wine can always play the It's not documented to work that way card but the bottom line is still that it is not a platform that we are interested in devoting time to. cgf -- Problem

Re: bug report: 64-bit cygwin setup crashes under Wine

On 9/4/2013 15:54, Earnie Boyd wrote: On Wed, Sep 4, 2013 at 5:26 PM, Warren Young wrote: Wine is cheaper than a VM in terms of hardware requirements and licensing. You must have some very expensive hardware. I figure a VM costs me $25-50 in RAM and SSD space. Because it's not a full OS,

bug report: 64-bit cygwin setup crashes under Wine

Howdy, I recently noticed the 64-bit cygwin installer crashes under wine. After further debugging, it appears that the issue is that cygwin is misaligning the stack, causing a crash. I've copy/pasted the analysis below: Hello folks, confirming. Reminded me of bug 27680 (violation of the

Re: bug report: 64-bit cygwin setup crashes under Wine

On Tue, Sep 03, 2013 at 10:08:44PM -0700, Austin English wrote: I recently noticed the 64-bit cygwin installer crashes under wine. After further debugging, it appears that the issue is that cygwin is misaligning the stack, causing a crash. I've copy/pasted the analysis below: Hello folks,

Re: [BUG REPORT]sed -e 's/[B-D]/_/g' replaces unexpected characters

On Jun 25 18:09, Corinna Vinschen wrote: On Jun 25 18:03, Corinna Vinschen wrote: On Jun 25 15:38, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: Your locale is zh_CN.UTF-8. What you're expecting is only guaranteed in the C locale: [...] Which also means, AFAICS, Cygwin's sed is doing

  1   2   3   4   >