Re: Cygwin 3.3.0 regression: "make" segmentation faults
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=0018017516C [...] It does not look particularly useful to me, I was hoping for symbol Indeed names to be resolved, to be honest. I don't know what I am supposed to do next. There is no "core" around, as far as I can see... You can use 'export CYGWIN="error_start=dumper"' to get a coredump written on fatal signal. Or if you're just going to load that into gdb, save steps with 'export CYGWIN="error_start=gdb"' -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.3.0 regression: "make" segmentation faults
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 binary, I could then verify the fix. -- Thanks, -Aleksey -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.3.0 regression: "make" segmentation faults
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 reproduces locally for me, with the standard OpenJDK Windows build. > All sightings we had > are on Windows 10, but it is unclear if it is Windows 10 specific. > > The reproducer would be a bit hairy, because it requires MSVC 2019, JDK 17 > binary, and some other > dependencies to be installed for OpenJDK build. It goes like this: > > --- 8< --- --- --- --- --- --- --- --- > > > $ git clone https://github.com/openjdk/jdk/ jdk > $ cd jdk > $ sh ./configure --with-boot-jdk= --disable-warnings-as-errors > $ make clean jdk > ... > Compiling 8 files for BUILD_TOOLS_LANGTOOLS > Compiling 1 files for BUILD_TOOLS_HOTSPOT > Compiling 12 properties into resource bundles for jdk.jdeps > /usr/bin/bash: line 1: 1588 Segmentation fault (core dumped) > /usr/bin/make -s -r -R -I > /cygdrive/d/a/jdk17u/jdk17u/jdk/make/common > SPEC=/cygdrive/d/a/jdk17u/jdk17u/jdk/build/windows-x64/spec.gmk > MAKE_LOG_FLAGS="-s" -f > ModuleWrapper.gmk -I /cygdrive/d/a/jdk17u/jdk17u/jdk/make/common/modules > -I/cygdrive/d/a/jdk17u/jdk17u/jdk/make/modules/java.base MODULE=java.base > MAKEFILE_PREFIX=Copy > make[2]: *** [make/Main.gmk:157: java.base-copy] Error 139 > make[2]: *** Waiting for unfinished jobs > Compiling 7 properties into resource bundles for jdk.jshell > > --- 8< --- --- --- --- --- --- --- --- 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. -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.3.0 regression: "make" segmentation faults
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 would be appreciated. I have a working Windows VM where this issue reliably reproduces. Perhaps an easier way to follow up on this is to use me as remote hands. After installing make-devel and doing "ulimit -c unlimited", I have got this stackdump: Exception: STATUS_ACCESS_VIOLATION at rip=0018017516C rax=0001 rbx=0008004BE630 rcx=0001 rdx= rsi=0008 rdi=0001 r8 =FFF1 r9 =0001 r10=000180320880 r11=0008 r12=0001 r13=000180243A80 r14= r15= rbp=000800403440 rsp=99B0 program=C:\cygwin64\bin\make.exe, pid 61490, thread main cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args 00800403440 0018017516C (00100438940, 008, 001, 00800403440) 00800403440 001800D7C68 (0009BE7, 000, 0009BE7, 008004035E0) 00800403440 0018018EB0B (0009BE7, 000, 0009BE7, 008004035E0) 00800403440 0010040F513 (000E410, 001802A4CB0, 00180366E08, 00800071DB0) 000 0010040F68C (000, 001801402B0, 0009B20, 00100427E70) 00100427D70 001004104E3 (000, 000, 006, 000) 0009CD0 00100410D5F (7A01C9E544B96FAD, 00100419ED2, 001803231A0, 00800323460) 0080034D8A0 0010041C15F (006, 002, 000, 000) 000 0010041C55E (000, 000, 000, 000) 000 0010041B5B0 (004, 006FFB9, 303E9F032, 00180267740) 000 0010041C55E (000, 68F5F1EE9D7B, 000, 103) 000 0010041B5B0 (002, 000, 001, 000) 000 0010041C55E (000800D7C68, 000, 000A2E8, 008001DA120) 000 0010041B5B0 (534544, 6176652D2A2D2824, 2D7367616C662D6C, 0292D2A) 00100435590 0010041C985 (000, 001803231A0, 00800075740, 00100429B21) 000B360 00100426324 (001801B609A, 000, 000, 000CD30) 000CD30 00180049B8D (000, 000, 000, 000) 000FFF0 00180047746 (000, 000, 000, 000) 000FFF0 001800477F4 (000, 000, 000, 000) End of stack trace It does not look particularly useful to me, I was hoping for symbol names to be resolved, to be honest. I don't know what I am supposed to do next. There is no "core" around, as far as I can see... install make-debuginfo and cygwin-debuginfo than you can use addr2line to find the proper info an example on: https://stackoverflow.com/questions/37628530/how-to-debug-using-stackdump-file-in-cygwin/37629946#37629946 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Cygwin 3.3.0 regression: "make" segmentation faults
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. All sightings we had are on Windows 10, but it is unclear if it is Windows 10 specific. The reproducer would be a bit hairy, because it requires MSVC 2019, JDK 17 binary, and some other dependencies to be installed for OpenJDK build. It goes like this: --- 8< --- --- --- --- --- --- --- --- $ git clone https://github.com/openjdk/jdk/ jdk $ cd jdk $ sh ./configure --with-boot-jdk= --disable-warnings-as-errors $ make clean jdk ... Compiling 8 files for BUILD_TOOLS_LANGTOOLS Compiling 1 files for BUILD_TOOLS_HOTSPOT Compiling 12 properties into resource bundles for jdk.jdeps /usr/bin/bash: line 1: 1588 Segmentation fault (core dumped) /usr/bin/make -s -r -R -I /cygdrive/d/a/jdk17u/jdk17u/jdk/make/common SPEC=/cygdrive/d/a/jdk17u/jdk17u/jdk/build/windows-x64/spec.gmk MAKE_LOG_FLAGS="-s" -f ModuleWrapper.gmk -I /cygdrive/d/a/jdk17u/jdk17u/jdk/make/common/modules -I/cygdrive/d/a/jdk17u/jdk17u/jdk/make/modules/java.base MODULE=java.base MAKEFILE_PREFIX=Copy make[2]: *** [make/Main.gmk:157: java.base-copy] Error 139 make[2]: *** Waiting for unfinished jobs Compiling 7 properties into resource bundles for jdk.jshell --- 8< --- --- --- --- --- --- --- --- I have managed to bisect this in Cygwin to the difference between 3.2.0 and 3.3.0. Downgrading cygwin package to 3.2.0 workarounds this bug. This is the fix we are currently deploying in our build infra: https://github.com/openjdk/jdk/commit/403f3185f0988dcf6ef4e857d6659533bfa2943f ...but, of course, this is living on borrowed time, while 3.2.0 version is still available. Any help would be appreciated. I have a working Windows VM where this issue reliably reproduces. Perhaps an easier way to follow up on this is to use me as remote hands. After installing make-devel and doing "ulimit -c unlimited", I have got this stackdump: Exception: STATUS_ACCESS_VIOLATION at rip=0018017516C rax=0001 rbx=0008004BE630 rcx=0001 rdx= rsi=0008 rdi=0001 r8 =FFF1 r9 =0001 r10=000180320880 r11=0008 r12=0001 r13=000180243A80 r14= r15= rbp=000800403440 rsp=99B0 program=C:\cygwin64\bin\make.exe, pid 61490, thread main cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: FrameFunctionArgs 00800403440 0018017516C (00100438940, 008, 001, 00800403440) 00800403440 001800D7C68 (0009BE7, 000, 0009BE7, 008004035E0) 00800403440 0018018EB0B (0009BE7, 000, 0009BE7, 008004035E0) 00800403440 0010040F513 (000E410, 001802A4CB0, 00180366E08, 00800071DB0) 000 0010040F68C (000, 001801402B0, 0009B20, 00100427E70) 00100427D70 001004104E3 (000, 000, 006, 000) 0009CD0 00100410D5F (7A01C9E544B96FAD, 00100419ED2, 001803231A0, 00800323460) 0080034D8A0 0010041C15F (006, 002, 000, 000) 000 0010041C55E (000, 000, 000, 000) 000 0010041B5B0 (004, 006FFB9, 303E9F032, 00180267740) 000 0010041C55E (000, 68F5F1EE9D7B, 000, 103) 000 0010041B5B0 (002, 000, 001, 000) 000 0010041C55E (000800D7C68, 000, 000A2E8, 008001DA120) 000 0010041B5B0 (534544, 6176652D2A2D2824, 2D7367616C662D6C, 0292D2A) 00100435590 0010041C985 (000, 001803231A0, 00800075740, 00100429B21) 000B360 00100426324 (001801B609A, 000, 000, 000CD30) 000CD30 00180049B8D (000, 000, 000, 000) 000FFF0 00180047746 (000, 000, 000, 000) 000FFF0 001800477F4 (000, 000, 000, 000) End of stack trace It does not look particularly useful to me, I was hoping for symbol names to be resolved, to be honest. I don't know what I am supposed to do next. There is no "core" around, as far as I can see... -- Thanks, -Aleksey Cygwin Configuration Diagnostics Current System Time: Wed Nov 10 10:19:41 2021 Windows 10 Professional Ver 10.0 Build 19041 Path: C:\cygwin64\usr\local\bin C:\cygwin64\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\WINDOWS\System32\WindowsPowerShell\v1.0 C:\WINDOWS\System32\OpenSSH C:\Users\test\AppData\Local\Programs\Microsoft VS Code\bin C:\Users\test\AppData\Local\Microsoft\WindowsApps Output from C:\cygwin64\b
RE: Very Slow Setup Parsing / was Re: Segmentation Faults
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
Re: Very Slow Setup Parsing / was Re: Segmentation Faults
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 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) Slowness. After the setup initial steps and pointing > to the local install location, I get to the following display > for 10s of minutes to hours (see log excerpt farther down). > It eventually goes to the next step. There is a very > low, steady network traffic during the delay. This > storage and network is usually fast for other things, > including during actual package installs. You might want to checkout the '-m --mirror-mode' option to setup. = = = = = Ken, Works great! Hoping my mirror stays "clean." 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 Thanks! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Very Slow Setup Parsing / was Re: Segmentation Faults
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) Slowness. After the setup initial steps and pointing to the local install location, I get to the following display for 10s of minutes to hours (see log excerpt farther down). It eventually goes to the next step. There is a very low, steady network traffic during the delay. This storage and network is usually fast for other things, including during actual package installs. You might want to checkout the '-m --mirror-mode' option to setup. Ken -- 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
Very Slow Setup Parsing / was Re: Segmentation Faults
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, including XWin, wget, curl, ssh, procps, top, gawk... > > This is 64 bit on Windos 7 "professional." > > Below is excerpt from the end of a strace of wget http://www.yahoo.com/ > > Is "windows error 2" easy to fix? :) Any bloda running around ? I will bet on some other program interfering on cygwin program execution or dll loading. ... Check also if all the DLL needed by wget, curl, ssh, procps, top, gawk are still there. I saw case where the Antivirus removed the dll's without big notice. = = = = = There is probably lots of bloda around, but that was not the problem. I suspect incompatible versions of some things, because of the way I'd been updating using apt-cyg following announcements. I started chasing down DLLs and dependencies, but it was too slow manually. Now I have a new, different slowness automatically. 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) Slowness. After the setup initial steps and pointing to the local install location, I get to the following display for 10s of minutes to hours (see log excerpt farther down). It eventually goes to the next step. There is a very low, steady network traffic during the delay. This storage and network is usually fast for other things, including during actual package installs. Is it searching through all the files in the mirror? Can I change something to make this faster? Setup Display: Cygwin Setup (Not Responding) Parsing... H:\home\... 100% (9704k/9704k) Package: [static progress bar] (2) I'm seeing the following error, and reporting as it suggests. It doesn't seem to cause any problem, but I can't change the permissions (non-admin) to make it go away. Package: _/Unknown package inetutils-server.sh exit code 1 check /var/log/setup.log.full and report any problems 2017/03/17 13:10:16 Starting cygwin install, version 2.877 2017/03/17 13:10:16 User has NO backup/restore rights 2017/03/17 13:10:16 Current Directory: H:\home\...\ftwin\mirror...\cygwin 2017/03/17 13:10:16 Could not open Service control manager ... Rebuilding info directory install-info: warning: no info dir entry in `/usr/share/info/abs_integrate.info' install-info: warning: no info dir entry in `/usr/share/info/automake-history.info.gz' install-info: warning: no info dir entry in `/usr/share/info/automake-history1.12.info.gz' install-info: warning: no info dir entry in `/usr/share/info/automake-history1.13.info.gz' install-info: warning: no info dir entry in `/usr/share/info/drawutils.info' install-info: warning: no info dir entry in `/usr/share/info/kovacicODE.info' install-info: warning: no info dir entry in `/usr/share/info/logic.info' install-info: warning: no info dir entry in `/usr/share/info/maxima-index.lisp' 2017/03/17 16:32:18 running: E:\cygwin64-3\bin\bash.exe --norc --noprofile "/etc/postinstall/mintty.sh" 2017/03/17 16:32:18 running: E:\cygwin64-3\bin\bash.exe --norc --noprofile "/etc/postinstall/inetutils-server.sh" *** Warning: The owner and the Administrators need *** Warning: to have .w. permission to /var/run. *** Warning: Here are the current permissions and ACLS: *** Warning: drwxr-xr-x 1 myuser Domain Users 0 Mar 14 17:48 /var/run *** Warning: # file: /var/run *** Warning: # owner: myuser *** Warning: # group: Domain Users *** Warning: user::rwx *** Warning: group::r-x *** Warning: other:r-x *** Warning: *** Warning: Please change the user and/or group ownership, *** Warning: permissions, or ACLs of /var/run. *** ERROR: Problem with /var/run directory. Exiting. *** Warning: The owner and the Administrators need *** Warning: to have .w. permission to /var/run. *** Warning: Here are the current permissions and ACLS: *** Warning: drwxr-xr-x 1 myuser Domain Users 0 Mar 14 17:48 /var/run *** Warning: # file: /var/run *** Warning: # owner: myuser *** Warning: # group: Domain Users *** Warning: user::rwx *** Warning: group::r-x *** Warning: other:r-x *** Warning: *** Warning: Please change the user and/or group ownership, *** Warning: permissions, or ACLs of /var/run. *** ERROR: Problem with /var/run directory. Exiting. 2017/03/17 16:32:26 abnormal exit: exit code=1 Error connecting to currency server. 2017/03/17 16:34:38 Ending cygwin install -- 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: Segmentation Faults
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 as much as before, and recovery is more difficult because of previously reported proxy issues with setup. procps and top worked after reverting to old versions for "required" packages, but I haven't been able to get wget to work, and apt-cyg is dead without gawk or wget. :( This is 64 bit on Windos 7 "professional." Below is excerpt from the end of a strace of wget http://www.yahoo.com/ Is "windows error 2" easy to fix? :) Any bloda running around ? I will bet on some other program interfering on cygwin program execution or dll loading. As example, recently strace is segfaulting on my W7 64 bit, and I am almost sure Symantec is the guilty guy. Check also if all the DLL needed by wget, curl, ssh, procps, top, gawk are still there. I saw case where the Antivirus removed the dll's without big notice. Regards Marco -- 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
Segmentation Faults
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 because of previously reported proxy issues with setup. procps and top worked after reverting to old versions for "required" packages, but I haven't been able to get wget to work, and apt-cyg is dead without gawk or wget. :( This is 64 bit on Windos 7 "professional." Below is excerpt from the end of a strace of wget http://www.yahoo.com/ Is "windows error 2" easy to fix? :) 21 258792 [main] wget 8408 fhandler_base::fstat_helper: 0 = fstat (\??\E:\cygwin64-2\dev, 0x1802E5A20) st_size=0, st_mode=040755, st_ino=32687320224st_atim=55FF8ED0.0 st_ctim=56003CF2.0 st_mtim=5600 3CF2.0 st_birthtim=56003CF0.1E65FB80 22 258814 [main] wget 8408 stat_worker: 0 = (\??\E:\cygwin64-2\dev,0x1802E5A20) 29 258843 [main] wget 8408 fstat64: 0 = fstat(3, 0xC920) 26 258869 [main] wget 8408 getrusage: 0 = getrusage(0, 0xC9F0) 17 258886 [main] wget 8408 getpid: 8408 = getpid() 16 258902 [main] wget 8408 read: read(3, 0xC970, 32) blocking --- Process 8408 loaded C:\Windows\System32\cryptbase.dll at 07fefcfe 9169 268071 [main] wget 8408 read: 32 = read(3, 0xC970, 32) 1572 269643 [main] wget 8408 read: read(3, 0xC970, 32) blocking 86 269729 [main] wget 8408 read: 32 = read(3, 0xC970, 32) 55 269784 [main] wget 8408 read: read(3, 0xC960, 8) blocking 73 269857 [main] wget 8408 read: 8 = read(3, 0xC960, 8) 63 269920 [main] wget 8408 getpid: 8408 = getpid() --- Process 8408, exception c005 at 0003e8448020 809 270729 [main] wget 8408 exception::handle: In cygwin_except_handler exception 0xC005 at 0x3E8448020 sp 0xCB68 22 270751 [main] wget 8408 exception::handle: In cygwin_except_handler signal 11 at 0x3E8448020 20 270771 [main] wget 8408 _cygtls::inside_kernel: pc 0x3E8448020, h 0x3E842, inside_kernel 0 21 270792 [main] wget 8408 normalize_posix_path: src /dev/kmsg 16 270808 [main] wget 8408 normalize_posix_path: /dev/kmsg = normalize_posix_path (/dev/kmsg) 16 270824 [main] wget 8408 mount_info::conv_to_win32_path: conv_to_win32_path (/dev/kmsg) 16 270840 [main] wget 8408 mount_info::conv_to_win32_path: src_path /dev/kmsg, dst \Device\MailSlot\cygwin\dev\kmsg, flags 0x2, rc 0 28 270868 [main] wget 8408 build_fh_pc: fh 0x1803171E0, dev 0001000B 25 270893 [main] wget 8408 seterrno_from_nt_status: /home/corinna/src/cygwin/cygwin-2.7.0/cygwin-2.7.0-0.1.x86_64/src/newlib-cygwin/winsup/cygwin/fhandler_mailslot.cc:132 status 0xC034 -> windows error 2 20 270913 [main] wget 8408 geterrno_from_win_error: windows error 2 == errno 2 17 270930 [main] wget 8408 sig_send: sendsig 0x98, pid 8408, signal 11, its_me 1 19 270949 [main] wget 8408 sig_send: wakeup 0x258 19 270968 [main] wget 8408 sig_send: Waiting for pack.wakeup 0x258 19 270987 [sig] wget 8408 sigpacket::process: signal 11 processing 24 271011 [sig] wget 8408 sigpacket::process: signal 11, signal handler 0x18005CD10 16 271027 [sig] wget 8408 sigpacket::setup_handler: controlled interrupt. stackptr 0xE458, stack 0xE458, stackptr[-1] 0xE458 19 271046 [sig] wget 8408 proc_subproc: args: 5, 1 15 271061 [sig] wget 8408 proc_subproc: clear waiting threads 14 271075 [sig] wget 8408 proc_subproc: finished clearing 14 271089 [sig] wget 8408 proc_subproc: returning 1 14 271103 [sig] wget 8408 _cygtls::interrupt_setup: armed signal_arrived 0x15C, signal 11 16 271119 [sig] wget 8408 sigpacket::setup_handler: signal 11 delivered 15 271134 [sig] wget 8408 sigpacket::process: returning 1 14 271148 [sig] wget 8408 wait_sig: signalling pack.wakeup 0x258 18 271166 [main] wget 8408 set_process_mask_delta: oldmask 0, newmask 0, deltamask 0 27 271193 [main] wget 8408 signal_exit: exiting due to signal 11 1953 273146 [main] wget 8408 cygwin_exception::open_stackdumpfile: Dumping stack trace to wget.exe.stackdump 155873 429019 [main] wget 8408 signal_exit: about to call do_exit (8B) 74 429093 [main] wget 8408 do_exit: do_exit (139), exit_state 2 37 429130 [main] wget 8408 void: 0x0 = signal (20, 0x1) 32 429162 [main] wget 8408 void: 0x0 = signal (1, 0x1) 27 429189 [main] wget 8408 void: 0x0 = signal (2, 0x1) 51 429240 [main] wget 8408 void: 0x0 = signal (3, 0x1) 34 429274 [main] wget 8408 fhandler_base::close_with_arch: line 1120: /dev/pty0<0x180316090> usecount + -1 = 2 31 429305 [main] wget 8408 fhandler_base::close_with_arch: not closing archetype 54 429359 [main] wget 8408 fhandler_base::close: closing '' handle 0x278 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation:
Re: launching sh/bash from windows console (cmd) results in application Segmentation Faults
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, or the terminal closes in any other way than my typing "exit" (or other exit type commands) then not all applications are closed (ssh-agent is regularly left open in this situation). -- 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: launching sh/bash from windows console (cmd) results in application Segmentation Faults
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 alternative and I don't have any > alternatives other than "C:\Windows\SysWOW64\cmd.exe" which is also > reported as 32 bit. That is because of redirection in Windows x64. When you need to access (or run) any 64-bit windows app in system folder from any 32-bit app, you need to use "sysnative" alias. $ file /c/windows/sysnative/cmd.exe /c/windows/sysnative/cmd.exe: PE32+ executable (console) x86-64, for MS Windows -- 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: launching sh/bash from windows console (cmd) results in application Segmentation Faults
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.7.28(0.271/5/3) 2014-02-09 21:06 x86_64 Cygwin I just installed cygwin32 and it works as expected (I have not seen any problems yet) CYGWIN_NT-6.1-WOW64 1.7.28(0.271/5/3) 2014-02-09 21:06 i686 Cygwin 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 alternative and I don't have any alternatives other than "C:\Windows\SysWOW64\cmd.exe" which is also reported as 32 bit. Any ideas or suggestions? -- 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: launching sh/bash from windows console (cmd) results in application Segmentation Faults
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 shell session terminates (for example ssh-agents and ssh processes remain and must be killed in task manager). This is also a problem when using cygwin from other shell environments such as console2 and conemu. 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. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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
launching sh/bash from windows console (cmd) results in application Segmentation Faults
==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 and ssh processes remain and must be killed in task manager). This is also a problem when using cygwin from other shell environments such as console2 and conemu. ==Environment== Windows 7 SP1 x64. Cygwin Version: CYGWIN_NT-6.1 1.7.25(0.270/5/3) 2013-08-31 20:37 x86_64 Cygwin -ssh-agent is present and run at startup Bash version: GNU bash, version 4.1.11(2)-release (x86_64-unknown-cygwin) ==Procedure== 1) Launch windows cmd 2) cd to cygwin bin dirctory 3) Execute "sh.exe --login -i" or "sh.exe --login" or "sh.exe -i" 4) Run "ps", "ls", "cat" processes 3 times each. 5) If segmentation faults are not observed run "ssh-add " and repeat step 4. ==Stack Dumps== 1) Exception: STATUS_ACCESS_VIOLATION at rip=001800A6DDC rax=0003 rbx=0001802DF958 rcx=0001802DF958 rdx=01E2 rsi=0001 rdi= r8 =0008 r9 =0001 r10=0023 r11=000100411C89 r12=0022AA68 r13= r14=0022AA70 r15= rbp=0022AB20 rsp=0022A940 program=C:\cygwin64\bin\ls.exe, pid 5900, thread main cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: FrameFunctionArgs 022AB20 001800A6DDC (000, 022AB20, 022AA68, 000) 022AB20 00180134677 (003FEFC8180, 022AA70, 001, 022AA68) 022AB20 001801130AB (022AA70, 001, 022AA68, 0010040E770) 022AB20 0010003 (001, 022AA68, 0010040E770, 001802BD480) 022AB20 003FEFC8180 (022AA68, 0010040E770, 001802BD480, 022AA68) 022AB20 022AA70 (0010040E770, 001802BD480, 022AA68, 001802A6740) 022AB20 001 (001802BD480, 022AA68, 001802A6740, 001802A6740) 022AB20 022AA68 (022AA68, 001802A6740, 001802A6740, 001802A6740) 022AB20 0010040E770 (001802A6740, 001802A6740, 001802A6740, 001801736C0) 022AB20 001802BD480 (001802A6740, 001802A6740, 001801736C0, 001) 022AB20 022AA68 (001802A6740, 001801736C0, 001, 000) 022AB20 001802A6740 (001801736C0, 001, 000, 04900720019) 022AB20 001802A6740 (001, 000, 04900720019, 00180163CAA) 022AB20 001802A6740 (000, 04900720019, 00180163CAA, 001802DD820) 022AB20 001801736C0 (04900720019, 00180163CAA, 001802DD820, 001802DEE08) 022AB20 001 (04900720019, 00180163CAA, 001802DD820, 001802DEE08) End of stack trace (more stack frames may be present) 2) Exception: STATUS_ACCESS_VIOLATION at rip=0018007A5AB rax=003F rbx=00228F30 rcx=779666DA rdx=0014 rsi=0001802E3BD8 rdi=0004 r8 =00228AC8 r9 =00228D20 r10= r11=0246 r12=0020 r13=0001 r14=0001 r15=0001 rbp=00228D20 rsp=00228C10 program=C:\cygwin64\bin\ssh-add.exe, pid 3900, thread main cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: FrameFunctionArgs 0228D20 0018007A5AB (0010041F160, 02294E0, 000, 02294B0) 0228D20 001801341DA (000, 400, 000, 0228DEF) 0010041F160 001801130AB (400, 000, 0228DEF, 022942F) 0010041F160 0471900 (400, 000, 0228DEF, 022942F) End of stack trace -- 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: Random segmentation faults since upgrade to Cygwin 1.7.16
On 8/9/2012 9:33 PM, Buist, Eric wrote: Hi, I am running Cygwin 1.7 under Windows 7 64 bits for some time without problems, except it is sometimes slow when performing tab completion. But after I upgraded to Cygwin 1.7.16, no more Cygwin tool is working correctly. Even simple commands such as ls, uname, dirname, or bash -version return nothing or crash with segmentation fault. I tried using the setup to downgrade to Cygwin 1.7.15 without success. I tried reinstalling Cygwin completely and got the 1.7.16 again, without any change. I then tried downgrading to Cygwin 1.7.9 from an old tar.bz2 file I had. I got a bit more 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 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 something that was working correctly before. I don't have any old downloaded Cygwin files I could use to reinstall a complete old stack so I am quite stuck. If a complete reinstall of all packages didn't resolve the problem, I'd suspect one of the following FAQs are coming into play: <http://cygwin.com/faq-nochunks.html#faq.using.multiple-copies> <http://cygwin.com/faq-nochunks.html#faq.using.bloda> <http://cygwin.com/faq-nochunks.html#faq.using.fixing-fork-failures> It's also possible that you just installed with some Cygwin process (perhaps a service) still running. Try a reboot. If none of the above helps, please see the problem reporting guidelines found at the link below. Problem reports: http://cygwin.com/problems.html This will help you formulate a complete problem report with any follow-up posting. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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
Random segmentation faults since upgrade to Cygwin 1.7.16
Hi, I am running Cygwin 1.7 under Windows 7 64 bits for some time without problems, except it is sometimes slow when performing tab completion. But after I upgraded to Cygwin 1.7.16, no more Cygwin tool is working correctly. Even simple commands such as ls, uname, dirname, or bash -version return nothing or crash with segmentation fault. I tried using the setup to downgrade to Cygwin 1.7.15 without success. I tried reinstalling Cygwin completely and got the 1.7.16 again, without any change. I then tried downgrading to Cygwin 1.7.9 from an old tar.bz2 file I had. I got a bit more 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 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 something that was working correctly before. I don't have any old downloaded Cygwin files I could use to reinstall a complete old stack so I am quite stuck. Thanks in advance. Eric Buist, Ph.D Research Engineer | Natural Language Understanding Nuance Communications, Inc. 1500 University - Suite 935 Montreal, QC H3A 3S7 Tel: (514) 904-7800 - "Just say my name" Fax: (514) 940-6826 eric.bu...@nuance.com === This email and its attachments are Confidential Information of Nuance Communications, Inc. -- 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 > 1.7.9: Segmentation faults / STATUS_STACK_OVERFLOW
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, NULL); > > [...] > > Jep, that works for me. Apart from that I set the default stack size to 1 Megs. Thanks for your testcase, btw. It helped me a lot to understand how Windows handles the stack and the stack guard pages. With its help I also found two long-standing problems in glob(). When I added the glob implementation from FreeBSD, I made some innocent changes which turned out to waste a lot of stack space. And, at the time we had no locale support so I removed it from the code, so I took the opportunity to add locale support back into the code. I'm still testing one of my changes before checking in, but I'm almost GTG. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 > 1.7.9: Segmentation faults / STATUS_STACK_OVERFLOW
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
Re: cygwin > 1.7.9: Segmentation faults / STATUS_STACK_OVERFLOW
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
> > // Not working if called in another thread.
>
> pthread_attr_t attr;
> pthread_attr_init (&attr);
> pthread_attr_setstacksize (&attr, 1024 * 1024);
>
> > ret = pthread_create(&threadId, NULL, callGlob, NULL);
Oops, sorry, you have to change the pthread_create call so that it uses
attr, of course:
ret = pthread_create (&threadId, &attr, callGlob, NULL);
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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 > 1.7.9: Segmentation faults / STATUS_STACK_OVERFLOW
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" Is that the correct maximum stack size in KiB that is relevant for
> me?
The default stacksize for the main thread is 2 Megs. The default
stacksize of subsequently called pthreads is 512K. In the below case
that's apparently not enough since the /proc/$PID/cmdline functionality
needs a lot of stack space. The SEGV is a result of a stack overflow
again. I can't tell why it only occurs under GDB, though.
However, I'm wondering if we should set the default stacksize for pthreads
to 1 Megs, as is the default for any other Windows thread...
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
> // Not working if called in another thread.
pthread_attr_t attr;
pthread_attr_init (&attr);
pthread_attr_setstacksize (&attr, 1024 * 1024);
> ret = pthread_create(&threadId, NULL, callGlob, NULL);
> [...]
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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 > 1.7.9: Segmentation faults / STATUS_STACK_OVERFLOW
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" Is that the correct maximum stack size in KiB that is relevant for
me?
Now about the segmentation fault. It seems like the problem only occurs when
calling glob in an own thread, using some special search string and only during
gdb debugging. See the test case below, I hope it helps.
Thanks in advance.
Regards,
Manuel
#include
#include
#include
#include
#include
pthread_t threadId;
void * callGlob(void * data)
{
glob_tinfo;
int i;
char searchStr[] = "/proc/[0-9]*/cmdline"; // Crashing on debug
//char searchStr[] = "/proc/1234/cmdline";
//char searchStr[] = "*.no";
//char searchStr[] = "./Debug/*.exe";
glob(searchStr, GLOB_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 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 latest
> snapshot dll. I'm quite sure it has something to do with the dll, because I
> did clean and rebuild with newest
> > cygwin versions. Since this wasn't working, I got my old dll (from
> 29.03.2011) and it worked again. I tried some other snapshot versions (up to
> 04.06.2011, since there are no old ones),
> > but none of them worked.
> >
> > If I can get older snapshot versions, I might be able to track it down. But
> then again stack problems are hard to catch.
> > I compiled my code with -fstack-protector-all --param ssp-buffer-size=4, but
> this didn't help me so far (well, maybe I'm not using it right.).
> >
> > Stacktrace of the first segmentation fault:
> > Thread [11] 0 (Suspended : Signal : SIGSEGV:Segmentation fault)
> > _alloca() at ../../../libgcc/../gcc/config/i386/cygwin.asm:45 0x6116fd02
> > __small_vswprintf() at /netrel/src/cygwin-snapshot-20120202-
> 1/winsup/cygwin/smallprint.cc:369 0x610dbdfe
> > 0x0
>
> Can you please create a simple testcase, in plain C, which allows to
> reproduce the problem with minimal code?
>
>
> Thanks,
> Corinna
>
> --
> Corinna Vinschen Please, send mails regarding Cygwin to
> Cygwin Project Co-Leader cygwin AT cygwin DOT com
> Red Hat
>
> --
> 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
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
Re: cygwin > 1.7.9: Segmentation faults / STATUS_STACK_OVERFLOW
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 latest > snapshot dll. I'm quite sure it has something to do with the dll, because I > did clean and rebuild with newest > cygwin versions. Since this wasn't working, I got my old dll (from > 29.03.2011) and it worked again. I tried some other snapshot versions (up to > 04.06.2011, since there are no old ones), > but none of them worked. > > If I can get older snapshot versions, I might be able to track it down. But > then again stack problems are hard to catch. > I compiled my code with -fstack-protector-all --param ssp-buffer-size=4, but > this didn't help me so far (well, maybe I'm not using it right.). > > Stacktrace of the first segmentation fault: > Thread [11] 0 (Suspended : Signal : SIGSEGV:Segmentation fault) > _alloca() at ../../../libgcc/../gcc/config/i386/cygwin.asm:45 0x6116fd02 > __small_vswprintf() at > /netrel/src/cygwin-snapshot-20120202-1/winsup/cygwin/smallprint.cc:369 > 0x610dbdfe > 0x0 Can you please create a simple testcase, in plain C, which allows to reproduce the problem with minimal code? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 > 1.7.9: Segmentation faults / STATUS_STACK_OVERFLOW
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 something to do with the dll, because I did clean and rebuild with newest cygwin versions. Since this wasn't working, I got my old dll (from 29.03.2011) and it worked again. I tried some other snapshot versions (up to 04.06.2011, since there are no old ones), but none of them worked. If I can get older snapshot versions, I might be able to track it down. But then again stack problems are hard to catch. I compiled my code with -fstack-protector-all --param ssp-buffer-size=4, but this didn't help me so far (well, maybe I'm not using it right.). Stacktrace of the first segmentation fault: Thread [11] 0 (Suspended : Signal : SIGSEGV:Segmentation fault) _alloca() at ../../../libgcc/../gcc/config/i386/cygwin.asm:45 0x6116fd02 __small_vswprintf() at /netrel/src/cygwin-snapshot-20120202-1/winsup/cygwin/smallprint.cc:369 0x610dbdfe 0x0 Another segmentation fault: It can be triggered with my program after continuing when the firs tsegmentation fault. I wasn't able to step into XCP_XmlResp_Ok. I checked the address of XCP_XmlResp_Ok, it stays the same from the program start. Thread [19] 0 (Suspended : Signal : SIGSEGV:Segmentation fault) _alloca() at /gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/libgcc/../gcc/config/i386/cygwin.asm:45 0x44ca42 XCP_XmlResp_Ok() at /cygdrive/c/.../XmlConfigParsing.c:2.278 0x409310 _fu82stack_chk_guard() at /cygdrive/c/.../XmlConfigParsing.c:517 0x4051c2 _fu80stack_chk_guard() at /cygdrive/c/.../XmlConfigParsing.c:166 0x404632 _fu434stack_chk_guard() at /cygdrive/c/.../TcpIpServer.c:331 0x41843e _fu427stack_chk_guard() at /cygdrive/c/.../TcpIpServer.c:82 0x4179fb pthread::thread_init_wrapper() at 0x610fa5d2 thread_wrapper() at 0x61085482 Regards, Manuel -- 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: Segmentation faults?
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 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
Segmentation faults?
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.exe.stackdump from the most recent occurrence in case it might be of any use. This also happened in 1.7.0-62 but I think that's the first version where I noticed it. Thanks, -- Lee Maschmeyer Wayne State University Detroit, Michigan, USA tput.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: segmentation faults and memory problems
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 com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
segmentation faults and memory problems
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 failed. I found in the FAQs some solutions like increasing cygwin's memory using regtool. And it is still failing. I ran the "max_memory" code given in the FAQ and it always gives 1536.0Mb and it is very weird... 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 for both computers and for any "heap_chunk_in_mb" value (so i think i am not RAM limitted ref:<[EMAIL PROTECTED]>) I'm running out of solutions. Can someone help? I attach the cygcheck.out file for the first computer. Tea Eric PhD student, IEF, Université Paris-Sud, FRANCE cygcheck.out Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: segmentation faults and memory problems
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 for both > computers and for any "heap_chunk_in_mb" value (so i think i > am not RAM limitted It doesn't matter how much physical memory you have. 32 bit Windows (and note that when using Cygwin with XP x64 you are still using 32 bit mode, WOW64, as there is no x64 Cygwin) partitions the virtual memory space into 2GB for kernel mode and 2GB for user mode. So you start out with a hard limit of 2GB of virtual address space, from which is subtracted the virtual memory of all DLLs, mappings, the stack, etc. in the process. For a single allocation, a limit of 1.5 GB sounds about right, given that the space is greatly fragmented by all those DLLs. There is a /3GB switch you can add to boot.ini which changes the partitioning to 3GB user mode and 1GB kernel mode. However, in order for apps to take advantage of this they have to be recompiled with a "/3GB aware" flag set in their PE header. And I'm not even sure if Cygwin can work in this mode; check the archives. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
segmentation faults and memory problems
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 failed. I found in the FAQs some solutions like increasing cygwin's memory using regtool. And it is still failing. I ran the "max_memory" code given in the FAQ and it always gives 1536.0Mb and it is very weird... 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 for both computers and for any "heap_chunk_in_mb" value (so i think i am not RAM limitted ref:<[EMAIL PROTECTED]>) I'm running out of solutions. Can someone help? I attach the cygcheck.out file for the first computer. Tea Eric PhD student, IEF, Université Paris-Sud, FRANCE cygcheck.out Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Gdb and stopping at assert or segmentation faults
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-28-cvs (cygwin-special) gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) In fact, it will now break before entering main(), but not when the assert is called. Using "break __assert" says (gdb) break __assert Breakpoint 1 at 0x4ac3e6: file /usr/lib/gcc/i686-pc- cygwin/3.4.4/include/c++/iostream, line 77. (gdb) r Starting program: /home/kris/MyDocuments/mytest.exe Breakpoint 1, __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/iostream:77 (gdb) c assertion "overlap>-epsilon" failed: file "./include/stir/numerics/overlap_interpolate.inl", line 108 Program exited normally. Any other suggestions? Thanks Kris -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Gdb and stopping at assert or segmentation faults
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: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Gdb and stopping at assert or segmentation faults
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 __assert" works for catching the assertions. Dunno what's up with the SEGVs. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Gdb and stopping at assert or segmentation faults
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 launch a program from within gdb: Gdb myprog Run Info stack > You can also call cygwin_internal (CW_DEBUG_SELF, > "c:\\path\\to\\gdb.exe") in your code to force a fault. > Ok. That's useful as well. Thanks! Kris -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Gdb and stopping at assert or segmentation faults
Kris Thielemans wrote: > I need to debug a program that throws up an assert(). On Linux, I'm used to > be able to run the program in gdb, and when the assert happens, the program > stops (in the assert function) and I can do a back trace (e.g. info stack). > On cygwin on the other 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 fault happened after the crash. You need to set the 'error_start' parameter of the CYGWIN environment variable to the (windows) path of gdb. You can also call cygwin_internal (CW_DEBUG_SELF, "c:\\path\\to\\gdb.exe") in your code to force a fault. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Gdb and stopping at assert or segmentation faults
Hi I need to debug a program that throws up an assert(). On Linux, I'm used to be able to run the program in gdb, and when the assert happens, the program stops (in the assert function) and I can do a back trace (e.g. info stack). On cygwin on the other 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 fault happened after the crash. Anyone knows how to change this behaviour on cygwin? Many thanks Kris Thielemans Hammersmith Imanet Ltd PS: please reply-all such that I get your reply directly in my box as I read this list via the mail archive. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Latest Cygwin/cdrtools - gcc Segmentation faults
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://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Latest Cygwin/cdrtools - gcc Segmentation faults
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 compiling it for years without errors > including with the previous version of cygwin. > > Any one else having this problem ? It builds fine for me without any core dumps with stock gcc 3.3.3 and a relatively recent CVS build of the DLL. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Latest Cygwin/cdrtools - gcc Segmentation faults
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> for instructions." > >I've been compiling it for years without errors including with the >previous version of cygwin. http://sources.redhat.com/ml/cygwin/2005-04/msg00504.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Latest Cygwin/cdrtools - gcc Segmentation faults
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 errors including with the previous version of cygwin. Any one else having this problem ? If you'd like to try it goto ftp://ftp.berlios.de/pub/cdrecord/alpha/ and download cdrtools-2.01.01a01.tar.gz *** read 1st The readme.win32 file has instructions for compiling with Cygwin. What you need to know from it is : "... unpack it with 'gnutar' or 'star', e.g. Start a bash command line window and type: star -xpz < cdrtools-2.01.01a01.tar.gz don't use winzip to unpack the tar archive, it will not unpack symlinks correctly. Then (from the bash command line window) run 'make' ... If you have problems with GNU make, get 'smake' from: ftp://ftp.berlios.de/pub/smake/alpha/ ..." *** I use 'star' to unpack it and 'smake' to compile. You'll find the relevant .exe files in the \OBJ\i686-cygwin32_nt-gcc\ subdirectories of cdda2wav, cdrecord, mkisofs and readcd or if you run 'smake install' it puts them all in \cygwin\opt\schily\bin\ thanks for any responses, Bill Mudd -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Segmentation faults with g++ 4.0
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
>
> > segmentation faults in pthread_specific on execution:
> >
> > #include
> > #include
> >
> > static const std::locale l;
> > //static std::ostream& o = std::cerr;
> >
> > int main(const int,
> > const char * const * const)
> > {
> > return 0;
> > }
> >
> > Is this a known bug? The c++ that comes with Cygwin is way too old to
>
> compile
>
> > my code; I need at least 3.4.
>
> GCC-4.0.0 (C++) is very broken on cygwin.
> Have a look at test results, here:
>
> http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00544.html
>
> There is a problem with pthreads and the recently added weak-linkage
> support for windows targets.
>
> But I'm glad to see someone is keen enough to test the bleeding edge.
> Care to submit a bug report?
>
> http://gcc.gnu.org/bugzilla
>
> Danny
Thanks, Danny, I'll submit a bug report to GNU. I would have done that
initially, except I'm pretty sure that pthread_getspecific is in a Cygwin
dll, not part of g++. Also, g++ 4.0 is pretty solid on Alpha and Sun, at
least for my code.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Segmentation faults with g++ 4.0
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
>
> static const std::locale l;
> //static std::ostream& o = std::cerr;
>
> int main(const int,
> const char * const * const)
> {
> return 0;
> }
>
> Is this a known bug? The c++ that comes with Cygwin is way too old to
compile
> my code; I need at least 3.4.
>
GCC-4.0.0 (C++) is very broken on cygwin.
Have a look at test results, here:
http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00544.html
There is a problem with pthreads and the recently added weak-linkage
support for windows targets.
But I'm glad to see someone is keen enough to test the bleeding edge.
Care to submit a bug report?
http://gcc.gnu.org/bugzilla
Danny
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Segmentation faults with g++ 4.0
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
>
>static const std::locale l;
>//static std::ostream& o = std::cerr;
>
>int main(const int,
> const char * const * const)
>{
>return 0;
>}
>
>Is this a known bug? The c++ that comes with Cygwin is way too old to compile
>my code; I need at least 3.4.
Rerun 'setup.exe', choose the "Exp" radio button above the package list,
and then click the "View" button until it shows "Partial". This will
give you a list of the packages that you have installed that have
"Experimental" versions available. "g++" and friends should be in that
list with a "3.4.1-1" version option. Cycle those packages you don't want
to change to "Keep". Leave "g++" and friend as is and click "Next" to
upgrade.
This is likely much easier than building your own version and tracking
down bugs in your configuration.
HTH,
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
838 Washington Street (508) 893-9889 - FAX
Holliston, MA 01746
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Segmentation faults with g++ 4.0
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::cerr;
int main(const int,
const char * const * const)
{
return 0;
}
Is this a known bug? The c++ that comes with Cygwin is way too old to compile
my code; I need at least 3.4.
Details are in the attachment.
log2.bz2
Description: BZip2 compressed data
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
