On 15/11/2021 16:47, Aleksey Shipilev via Cygwin wrote:
[...]
After installing make-devel and doing "ulimit -c unlimited", I have got
this stackdump:
For no particularly good reason, writing a core dump is not hooked up to
the core file size limit.
Exception: STATUS_ACCESS_VIOLATION at rip
On 11/16/21 9:11 AM, Takashi Yano wrote:
Thanks for the report.
I could reproduce the problem and found that the cause is
the same with:
https://cygwin.com/pipermail/cygwin/2021-November/249913.html
I will submit the patch for these issues shortly.
Nice. Let me know when there is a testable bi
On Mon, 15 Nov 2021 17:47:58 +0100
Aleksey Shipilev wrote:
> OpenJDK project uses Cygwin to drive the OpenJDK build system under Windows.
> Recently, our GitHub
> Actions (GHA) Windows runs started to fail with make SEGV-ing:
> https://bugs.openjdk.java.net/browse/JDK-8276854
>
> This also
On 15.11.2021 17:47, Aleksey Shipilev via Cygwin wrote:
Hi,
OpenJDK project uses Cygwin to drive the OpenJDK build system under
Windows. Recently, our GitHub Actions (GHA) Windows runs started to fail
with make SEGV-ing:
https://bugs.openjdk.java.net/browse/JDK-8276854
[cut]
Any help
Hi,
OpenJDK project uses Cygwin to drive the OpenJDK build system under Windows. Recently, our GitHub
Actions (GHA) Windows runs started to fail with make SEGV-ing:
https://bugs.openjdk.java.net/browse/JDK-8276854
This also reproduces locally for me, with the standard OpenJDK Windows build
From: Ian Lambert
> ...
> I missed the discussions of this "new" option,
> and documentation is the last thing to be updated.
> :)
> https://cygwin.com/faq.html#faq.setup.cli
It's also incorrect in saying that the listing is written to setup.log.
It seems to write to stdout instead.
--Ken Nellis
On Wed, 3/22/17, Ken Brown wrote:
Subject: Re: Very Slow Setup Parsing / was Re: Segmentation Faults
To: cygwin@cygwin.com
Date: Wednesday, March 22, 2017, 12:10 PM
On 3/22/2017 11:59 AM,
Ian Lambert via cygwin wrote:
> I've
now downloaded a complete cygwin mirror
>
onto
On 3/22/2017 11:59 AM, Ian Lambert via cygwin wrote:
I've now downloaded a complete cygwin mirror
onto a networked storage, done a new install, and
cygwin works OK again. However, doing updates or
package installs is (1) extremely slow, and (2) giving
a below reported permissions problem.
(1) Sl
On Wed, 2/8/17, Marco Atzeri wrote:
Subject: Re: Segmentation Faults
To: cygwin@cygwin.com
Date: Wednesday, February 8, 2017, 1:31 PM
On 08/02/2017 18:13, Ian
Lambert via cygwin wrote:
> FWIW, since
doing the updates late last month, many programs are seg
faulting for me, includ
On 08/02/2017 18:13, Ian Lambert via cygwin wrote:
FWIW, since doing the updates late last month, many programs are seg faulting
for me, including XWin, wget, curl, ssh, procps, top, gawk...
mintty, bash, vi, cd, and ls still work, so all is not lost, but I'm certainly
not able to use cygwin a
FWIW, since doing the updates late last month, many programs are seg faulting
for me, including XWin, wget, curl, ssh, procps, top, gawk...
mintty, bash, vi, cd, and ls still work, so all is not lost, but I'm certainly
not able to use cygwin as much as before,
and recovery is more difficult beca
The settings on my machine prevent windows automated updates from
running. The machine was pretty out of date and I manually ran
updates to bring it up snuff. That being said I am no longer seeing
the segmentation fault issues with the cygwin64 bit executables.
However if I close the terminal, o
Scott Mitchell gmail.com> writes:
> I am not sure if the is relevant but the "C:\Windows\System32\cmd.exe"
> I have been using is a 32 bit executable as reported by cygwin:
> $ file cmd.exe
> cmd.exe: PE32 executable (console) Intel 80386, for MS Windows
>
> I am not sure if this is an alternati
Do you have the same problem with Cygwin 32 bits? How about with
the current Cygwin package (1.7.28) with either 32 bits or 64?
I had no problem running this on 32-bits from W7 x64 with 1.7.28.
___
I still have the same problem when updating to cygwin64 to 1.7.28:
CYGWIN_NT-6.1 1
On 3/26/2014 1:35 PM, Scott Mitchell wrote:
==Problem==
When launching cygwin bash shell from windows command prompt (cmd)
then applications run by bash very frequently crash with Segmentation
Faults. When this occurs applications that are launched by the shell
are not cleaned up after the
==Problem==
When launching cygwin bash shell from windows command prompt (cmd)
then applications run by bash very frequently crash with Segmentation
Faults. When this occurs applications that are launched by the shell
are not cleaned up after the shell session terminates (for example
ssh-agents
segmentation faults about programs
compiled with GCC, but I am not compiling anything, just running precompiled
tools. Even if I reinstall Cygwin, I will get the new 1.7.16 DLL and that
will crash again. It seems I will really have to try this in a Windows XP
virtual machine, but that is a lot of work for
success, but dirname was returning nothing at all. I tried running as an
Administrator, tried Windows XP compatibility mode: no change. I tried a 1.7.17
snapshot Cygwin DLL: no change. Any search on Google or mailing list archives
give completely off-topic segmentation faults about programs compiled
On Feb 13 10:22, Manuel Wienand wrote:
> Hi Corinna,
>
> thanks for the info about the stack sizes.
>
> > [...]
> > pthread_attr_t attr;
> > pthread_attr_init (&attr);
> > pthread_attr_setstacksize (&attr, 1024 * 1024);
> >
> > ret = pthread_create(&threadId, &attr, callGlob,
Hi Corinna,
thanks for the info about the stack sizes.
> [...]
> pthread_attr_t attr;
> pthread_attr_init (&attr);
> pthread_attr_setstacksize (&attr, 1024 * 1024);
>
> ret = pthread_create(&threadId, &attr, callGlob, NULL);
> [...]
Jep, that works for me.
Manuel
On Feb 10 17:24, Corinna Vinschen wrote:
> Other than that, you can change the pthread stacksize since 1.7.10. Try
> this:
>
> > int main(void)
> > {
> > int ret;
> > puts("Starting test");
> >
> > #if 0
> > // Working fine if called in the main thread.
> > callGlob(NULL);
> > #else
> >
Hi Manuel,
please, don't http://cygwin.com/acronyms/#TOFU Thanks.
On Feb 10 13:40, Manuel Wienand wrote:
> Hi Corinna,
>
> ok, the STATUS_STACK_OVERFLOW problem is solved. Seems like a local variable
> with about 540 KiB caused the overflow. The Cygwin Shell gives me 2034 for
> "limit -s" I
NOSORT, NULL, &info );
printf("Found %d files.\n", info.gl_matchc);
for (i=0; i -Original Message-
> From: Corinna Vinschen
> Sent: Tuesday, February 07, 2012 5:46 PM
> Subject: Re: cygwin > 1.7.9: Segmentation faults / STATUS_STACK_OVERFLOW
>
> On F
On Feb 7 17:31, Manuel Wienand wrote:
> Hi,
>
> I have the problem that I get a segmentation fault on the newer versions of
> the cygwin1.dll when debugging and a STATUS_STACK_OVERFLOW exception when
> running without debugger.
> I did an update of my cygwin stuff on Monday, and I'm using the l
Hi,
I have the problem that I get a segmentation fault on the newer versions of the
cygwin1.dll when debugging and a STATUS_STACK_OVERFLOW exception when running
without debugger.
I did an update of my cygwin stuff on Monday, and I'm using the latest snapshot
dll. I'm quite sure it has somethin
On 05/11/2009 15:14, Lee Maschmeyer wrote:
I'm using cygwin 1.7.0-63 with everything installed. I get a
segmentation fault whenever I or any of my scripts issue the command:
tput clear
Are other people getting this?
http://cygwin.com/ml/cygwin/2009-10/msg00747.html
Yaakov
--
Problem report
Hi all,
I'm using cygwin 1.7.0-63 with everything installed. I get a segmentation
fault whenever I or any of my scripts issue the command:
tput clear
Are other people getting this? If not I'll have to go through the whole bug
reporting process but I thought I'd ask first. Attached is
tput.e
On Apr 14 14:26, Eric Tea wrote:
>
> Hi,
maybe you should read the replies you get before duplicating the same
message twice, which, btw., is quite rude.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT
Hi,
I try to run a program which needs a lot of memory.
It
fails with a "segmentation fault".
In the program's
Users Guide, it is advised to increase the stack size but as knwon the
"ulimit -s" command does not work.
So i tried to compile
the program with "-Wl,stack=..." option but it still fai
Eric Tea wrote:
> I work on two computers, running under
> windows XP and windows XP64. The former have 1Gb of RAM and the latter
> 4Gb.
> Increasing the stack size and modifying the
> "heap_chunk_in_mb" value dont change anything to my segmentation
> fault.
> Plus "max_memory" always reply 1536Mb
Hi,
I try to run a program which needs a lot of memory.
It
fails with a "segmentation fault".
In the program's
Users Guide, it is advised to increase the stack size but as knwon the
"ulimit -s" command does not work.
So i tried to compile
the program with "-Wl,stack=..." option but it still fa
Hi all
>
> Dave Korn artimi.com> writes:
>
> > >
> > Anyway, "break __assert" works for catching the assertions. Dunno what's
> > up with the SEGVs.
> >
well, it turns out Dave's suggestion doesn't work anymore on latest cygwin
(tested this only with C++ programs):
GNU gdb 6.3.50_2004-12
Dave Korn artimi.com> writes:
> >
> Anyway, "break __assert" works for catching the assertions. Dunno what's
> up with the SEGVs.
>
Hi Dave
I thought this would break even when the assertion didn't fail, but I was wrong
there!
Good suggestion! Thanks
Kris
--
Unsubscribe info: h
Original Message
>From: Kris Thielemans
>Sent: 29 June 2005 17:24
> However, what I was saying is that I would like to be able to backtrace
> when I launch a program from within gdb:
>
> Gdb myprog
> Run
>
> Info stack
Odd, I would have thought this should work.
Anyway, "break __
Hi Brian
> You need to set the 'error_start' parameter of the CYGWIN
> environment variable to the (windows) path of gdb.
>
I think what you're saying is that if I do this, it will launch gdb on the
crash? Ok.
However, what I was saying is that I would like to be able to backtrace when
I launc
ther hand, I just get the assert message, and then gdb
> says "Program exited normally". No backtrace possible.
>
> The same difference in behaviour between Linux and cygwin with segmentation
> faults. It would be incredibly useful to be able to see where the
> segmentation fa
, and then gdb
says "Program exited normally". No backtrace possible.
The same difference in behaviour between Linux and cygwin with segmentation
faults. It would be incredibly useful to be able to see where the
segmentation fault happened after the crash.
Anyone knows how to change th
I updated the cygwin1.dll with the latest snapshot
but got the same results.
I guess my cygwin installation is broken.
What can I do ? Do I have to re-install
everything ?
Thanks,
Bill Mudd
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygw
bill wrote:
> After the last cygwin update (1005.14.0.0),
> I compiled cdrtools-2.01.01a01 with gcc 3.3.3
> and got dozens of ...
>"Internal error: Segmentation fault (program cc1)
>Please submit a full bug report.
>See http://gcc.gnu.org/bugs.html> for instructions."
>
> I've been c
On Tue, Apr 12, 2005 at 12:56:44PM -0700, bill wrote:
>After the last cygwin update (1005.14.0.0),
>I compiled cdrtools-2.01.01a01 with gcc 3.3.3
>and got dozens of ...
> "Internal error: Segmentation fault (program cc1)
> Please submit a full bug report.
> See http://gcc.gnu.org/bugs.html>
After the last cygwin update (1005.14.0.0),
I compiled cdrtools-2.01.01a01 with gcc 3.3.3
and got dozens of ...
"Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions."
I've been compiling it for years without
On Sunday 12 December 2004 15:57 pm, Danny Smith wrote:
> James W. McKelvey wrote:
> > I installed CYGWIN_NT-5.1 a few days ago and then built g++ from the
>
> latest
>
> > CVS. Simple programs like the one below will compile and link, but
>
> then get
>
> >
James W. McKelvey wrote:
> I installed CYGWIN_NT-5.1 a few days ago and then built g++ from the
latest
> CVS. Simple programs like the one below will compile and link, but
then get
> segmentation faults in pthread_specific on execution:
>
> #include
> #include
>
> st
At 06:10 PM 12/12/2004, you wrote:
>I installed CYGWIN_NT-5.1 a few days ago and then built g++ from the latest
>CVS. Simple programs like the one below will compile and link, but then get
>segmentation faults in pthread_specific on execution:
>
>#include
>#include
>
>
I installed CYGWIN_NT-5.1 a few days ago and then built g++ from the latest
CVS. Simple programs like the one below will compile and link, but then get
segmentation faults in pthread_specific on execution:
#include
#include
static const std::locale l;
//static std::ostream& o = std::
45 matches
Mail list logo
