* unhandled C++ exceptions not propagating @ 2020-08-15 23:38 David McFarland 2020-08-16 3:25 ` JonY 2020-08-16 3:53 ` Takashi Yano 0 siblings, 2 replies; 17+ messages in thread From: David McFarland @ 2020-08-15 23:38 UTC (permalink / raw) To: cygwin I was just debugging a c++ app (b2 build system from boost), and noticed that it would appear to exit unexpectedly without an error. This turned out to be when an unhandled C++ exception was thrown. On a fresh install of cygwin with gcc-g++, this program will throw an exception from the std::string constructor: c++ -x c++ - <<END #include <string> int main() { std::string str(nullptr); return 0; } END When it's executed from the shell it returns zero, but execution stops at the exception. $ ./a; echo $? 0 When executed under gdb, the exception is caught, and the process exits non-zero when continued: (gdb) r Starting program: /home/corngood/a [New Thread 4300.0x1390] [New Thread 4300.0x1d24] [New Thread 4300.0x1d48] [New Thread 4300.0x80c] gdb: unknown target exception 0x20474343 at 0x7ff8d2cfa799 Thread 1 "a" received signal ?, Unknown signal. 0x00007ff8d2cfa799 in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (gdb) c Continuing. [Thread 4300.0x1d24 exited with code 541541187] [Thread 4300.0x1870 exited with code 541541187] [Thread 4300.0x1d48 exited with code 541541187] [Thread 4300.0x1390 exited with code 541541187] [Inferior 1 (process 4300) exited with code 04021641503] (gdb) When executed under strace, it exits with an error as expected: $ strace -o /dev/null a; echo $? 67 That's as far as I've investigated so far. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: unhandled C++ exceptions not propagating 2020-08-15 23:38 unhandled C++ exceptions not propagating David McFarland @ 2020-08-16 3:25 ` JonY 2020-08-16 3:53 ` Takashi Yano 1 sibling, 0 replies; 17+ messages in thread From: JonY @ 2020-08-16 3:25 UTC (permalink / raw) To: cygwin [-- Attachment #1.1: Type: text/plain, Size: 1714 bytes --] On 8/15/20 11:38 PM, David McFarland via Cygwin wrote: > > I was just debugging a c++ app (b2 build system from boost), and noticed > that it would appear to exit unexpectedly without an error. This turned > out to be when an unhandled C++ exception was thrown. > > On a fresh install of cygwin with gcc-g++, this program will throw an > exception from the std::string constructor: > > c++ -x c++ - <<END > #include <string> > int main() { std::string str(nullptr); return 0; } > END > > When it's executed from the shell it returns zero, but execution stops > at the exception. > > $ ./a; echo $? > 0 > > When executed under gdb, the exception is caught, and the process exits > non-zero when continued: > > (gdb) r > Starting program: /home/corngood/a > [New Thread 4300.0x1390] > [New Thread 4300.0x1d24] > [New Thread 4300.0x1d48] > [New Thread 4300.0x80c] > gdb: unknown target exception 0x20474343 at 0x7ff8d2cfa799 > Thread 1 "a" received signal ?, Unknown signal. > 0x00007ff8d2cfa799 in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll > (gdb) c > Continuing. > [Thread 4300.0x1d24 exited with code 541541187] > [Thread 4300.0x1870 exited with code 541541187] > [Thread 4300.0x1d48 exited with code 541541187] > [Thread 4300.0x1390 exited with code 541541187] > [Inferior 1 (process 4300) exited with code 04021641503] > (gdb) > > When executed under strace, it exits with an error as expected: > > $ strace -o /dev/null a; echo $? > 67 > > That's as far as I've investigated so far. Can you try if different (older) GCC versions exhibit the same problem? You'll need to recompile your example with said version as well. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: unhandled C++ exceptions not propagating 2020-08-15 23:38 unhandled C++ exceptions not propagating David McFarland 2020-08-16 3:25 ` JonY @ 2020-08-16 3:53 ` Takashi Yano 2020-08-16 13:21 ` Ken Brown 2020-08-16 14:17 ` David McFarland 1 sibling, 2 replies; 17+ messages in thread From: Takashi Yano @ 2020-08-16 3:53 UTC (permalink / raw) To: cygwin; +Cc: David McFarland On Sat, 15 Aug 2020 20:38:01 -0300 David McFarland via Cygwin <cygwin@cygwin.com> wrote: > > I was just debugging a c++ app (b2 build system from boost), and noticed > that it would appear to exit unexpectedly without an error. This turned > out to be when an unhandled C++ exception was thrown. > > On a fresh install of cygwin with gcc-g++, this program will throw an > exception from the std::string constructor: > > c++ -x c++ - <<END > #include <string> > int main() { std::string str(nullptr); return 0; } > END > > When it's executed from the shell it returns zero, but execution stops > at the exception. > > $ ./a; echo $? > 0 > > When executed under gdb, the exception is caught, and the process exits > non-zero when continued: > > (gdb) r > Starting program: /home/corngood/a > [New Thread 4300.0x1390] > [New Thread 4300.0x1d24] > [New Thread 4300.0x1d48] > [New Thread 4300.0x80c] > gdb: unknown target exception 0x20474343 at 0x7ff8d2cfa799 > Thread 1 "a" received signal ?, Unknown signal. > 0x00007ff8d2cfa799 in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll > (gdb) c > Continuing. > [Thread 4300.0x1d24 exited with code 541541187] > [Thread 4300.0x1870 exited with code 541541187] > [Thread 4300.0x1d48 exited with code 541541187] > [Thread 4300.0x1390 exited with code 541541187] > [Inferior 1 (process 4300) exited with code 04021641503] > (gdb) > > When executed under strace, it exits with an error as expected: > > $ strace -o /dev/null a; echo $? > 67 > > That's as far as I've investigated so far. Is this the same issue with https://cygwin.com/pipermail/cygwin/2019-October/242795.html ? As far as I tested, this does not occur in 32-bit cygwin. -- Takashi Yano <takashi.yano@nifty.ne.jp> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: unhandled C++ exceptions not propagating 2020-08-16 3:53 ` Takashi Yano @ 2020-08-16 13:21 ` Ken Brown 2020-08-16 13:52 ` Takashi Yano 2020-08-16 14:17 ` David McFarland 1 sibling, 1 reply; 17+ messages in thread From: Ken Brown @ 2020-08-16 13:21 UTC (permalink / raw) To: cygwin On 8/15/2020 11:53 PM, Takashi Yano via Cygwin wrote: > On Sat, 15 Aug 2020 20:38:01 -0300 > David McFarland via Cygwin <cygwin@cygwin.com> wrote: >> >> I was just debugging a c++ app (b2 build system from boost), and noticed >> that it would appear to exit unexpectedly without an error. This turned >> out to be when an unhandled C++ exception was thrown. >> >> On a fresh install of cygwin with gcc-g++, this program will throw an >> exception from the std::string constructor: >> >> c++ -x c++ - <<END >> #include <string> >> int main() { std::string str(nullptr); return 0; } >> END >> >> When it's executed from the shell it returns zero, but execution stops >> at the exception. >> >> $ ./a; echo $? >> 0 >> >> When executed under gdb, the exception is caught, and the process exits >> non-zero when continued: >> >> (gdb) r >> Starting program: /home/corngood/a >> [New Thread 4300.0x1390] >> [New Thread 4300.0x1d24] >> [New Thread 4300.0x1d48] >> [New Thread 4300.0x80c] >> gdb: unknown target exception 0x20474343 at 0x7ff8d2cfa799 >> Thread 1 "a" received signal ?, Unknown signal. >> 0x00007ff8d2cfa799 in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll >> (gdb) c >> Continuing. >> [Thread 4300.0x1d24 exited with code 541541187] >> [Thread 4300.0x1870 exited with code 541541187] >> [Thread 4300.0x1d48 exited with code 541541187] >> [Thread 4300.0x1390 exited with code 541541187] >> [Inferior 1 (process 4300) exited with code 04021641503] >> (gdb) >> >> When executed under strace, it exits with an error as expected: >> >> $ strace -o /dev/null a; echo $? >> 67 >> >> That's as far as I've investigated so far. > > Is this the same issue with > https://cygwin.com/pipermail/cygwin/2019-October/242795.html ? > > As far as I tested, this does not occur in 32-bit cygwin. This doesn't seem to be a new issue. I found the following report from 6 years ago, on Cygwin 1.7.30 with GCC 4.9.0: https://stackoverflow.com/questions/24402412/program-executed-on-cygwin-does-not-report-a-thrown-exception Ken ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: unhandled C++ exceptions not propagating 2020-08-16 13:21 ` Ken Brown @ 2020-08-16 13:52 ` Takashi Yano 2020-08-16 14:56 ` Ken Brown 0 siblings, 1 reply; 17+ messages in thread From: Takashi Yano @ 2020-08-16 13:52 UTC (permalink / raw) To: cygwin On Sun, 16 Aug 2020 09:21:24 -0400 Ken Brown via Cygwin <cygwin@cygwin.com> wrote: > On 8/15/2020 11:53 PM, Takashi Yano via Cygwin wrote: > > On Sat, 15 Aug 2020 20:38:01 -0300 > > David McFarland via Cygwin <cygwin@cygwin.com> wrote: > >> > >> I was just debugging a c++ app (b2 build system from boost), and noticed > >> that it would appear to exit unexpectedly without an error. This turned > >> out to be when an unhandled C++ exception was thrown. > >> > >> On a fresh install of cygwin with gcc-g++, this program will throw an > >> exception from the std::string constructor: > >> > >> c++ -x c++ - <<END > >> #include <string> > >> int main() { std::string str(nullptr); return 0; } > >> END > >> > >> When it's executed from the shell it returns zero, but execution stops > >> at the exception. > >> > >> $ ./a; echo $? > >> 0 > >> > >> When executed under gdb, the exception is caught, and the process exits > >> non-zero when continued: > >> > >> (gdb) r > >> Starting program: /home/corngood/a > >> [New Thread 4300.0x1390] > >> [New Thread 4300.0x1d24] > >> [New Thread 4300.0x1d48] > >> [New Thread 4300.0x80c] > >> gdb: unknown target exception 0x20474343 at 0x7ff8d2cfa799 > >> Thread 1 "a" received signal ?, Unknown signal. > >> 0x00007ff8d2cfa799 in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll > >> (gdb) c > >> Continuing. > >> [Thread 4300.0x1d24 exited with code 541541187] > >> [Thread 4300.0x1870 exited with code 541541187] > >> [Thread 4300.0x1d48 exited with code 541541187] > >> [Thread 4300.0x1390 exited with code 541541187] > >> [Inferior 1 (process 4300) exited with code 04021641503] > >> (gdb) > >> > >> When executed under strace, it exits with an error as expected: > >> > >> $ strace -o /dev/null a; echo $? > >> 67 > >> > >> That's as far as I've investigated so far. > > > > Is this the same issue with > > https://cygwin.com/pipermail/cygwin/2019-October/242795.html ? > > > > As far as I tested, this does not occur in 32-bit cygwin. > > This doesn't seem to be a new issue. I found the following report from 6 years > ago, on Cygwin 1.7.30 with GCC 4.9.0: > > https://stackoverflow.com/questions/24402412/program-executed-on-cygwin-does-not-report-a-thrown-exception Thanks for the information. But I still wonder why 32-bit and 64-bit cygwin behave differently. -- Takashi Yano <takashi.yano@nifty.ne.jp> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: unhandled C++ exceptions not propagating 2020-08-16 13:52 ` Takashi Yano @ 2020-08-16 14:56 ` Ken Brown 2020-08-16 22:38 ` Ken Brown 0 siblings, 1 reply; 17+ messages in thread From: Ken Brown @ 2020-08-16 14:56 UTC (permalink / raw) To: cygwin; +Cc: David McFarland On 8/16/2020 9:52 AM, Takashi Yano via Cygwin wrote: > On Sun, 16 Aug 2020 09:21:24 -0400 > Ken Brown via Cygwin <cygwin@cygwin.com> wrote: >> On 8/15/2020 11:53 PM, Takashi Yano via Cygwin wrote: >>> On Sat, 15 Aug 2020 20:38:01 -0300 >>> David McFarland via Cygwin <cygwin@cygwin.com> wrote: >>>> >>>> I was just debugging a c++ app (b2 build system from boost), and noticed >>>> that it would appear to exit unexpectedly without an error. This turned >>>> out to be when an unhandled C++ exception was thrown. >>>> >>>> On a fresh install of cygwin with gcc-g++, this program will throw an >>>> exception from the std::string constructor: >>>> >>>> c++ -x c++ - <<END >>>> #include <string> >>>> int main() { std::string str(nullptr); return 0; } >>>> END >>>> >>>> When it's executed from the shell it returns zero, but execution stops >>>> at the exception. >>>> >>>> $ ./a; echo $? >>>> 0 >>>> >>>> When executed under gdb, the exception is caught, and the process exits >>>> non-zero when continued: >>>> >>>> (gdb) r >>>> Starting program: /home/corngood/a >>>> [New Thread 4300.0x1390] >>>> [New Thread 4300.0x1d24] >>>> [New Thread 4300.0x1d48] >>>> [New Thread 4300.0x80c] >>>> gdb: unknown target exception 0x20474343 at 0x7ff8d2cfa799 >>>> Thread 1 "a" received signal ?, Unknown signal. >>>> 0x00007ff8d2cfa799 in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll >>>> (gdb) c >>>> Continuing. >>>> [Thread 4300.0x1d24 exited with code 541541187] >>>> [Thread 4300.0x1870 exited with code 541541187] >>>> [Thread 4300.0x1d48 exited with code 541541187] >>>> [Thread 4300.0x1390 exited with code 541541187] >>>> [Inferior 1 (process 4300) exited with code 04021641503] >>>> (gdb) >>>> >>>> When executed under strace, it exits with an error as expected: >>>> >>>> $ strace -o /dev/null a; echo $? >>>> 67 >>>> >>>> That's as far as I've investigated so far. >>> >>> Is this the same issue with >>> https://cygwin.com/pipermail/cygwin/2019-October/242795.html ? >>> >>> As far as I tested, this does not occur in 32-bit cygwin. >> >> This doesn't seem to be a new issue. I found the following report from 6 years >> ago, on Cygwin 1.7.30 with GCC 4.9.0: >> >> https://stackoverflow.com/questions/24402412/program-executed-on-cygwin-does-not-report-a-thrown-exception > > Thanks for the information. But I still wonder why 32-bit and 64-bit > cygwin behave differently. I'm no C++ expert, but my understanding after a brief internet search is that an uncaught exception is supposed to cause std::terminate to be called. So I installed gcc-debuginfo and ran the OP's test case under gdb with a breakpoint at 'terminate'. On 32-bit Cygwin I got the expected behavior: Thread 1 "exception_test" hit Breakpoint 1, std::terminate () at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/eh_terminate.cc:96 96 __atomic_load (&__terminate_handler, &func, __ATOMIC_ACQUIRE); (gdb) bt #0 std::terminate () at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/eh_terminate.cc:96 #1 0x57c45909 in __cxxabiv1::__cxa_throw (obj=obj@entry=0x800396e8, tinfo=tinfo@entry=0x57c646a8 <typeinfo for std::logic_error>, dest=0x57be6c60 <std::logic_error::~logic_error()>) at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/eh_throw.cc:95 #2 0x57c49223 in std::__throw_logic_error ( __s=__s@entry=0x57c60160 <cplus_demangle_builtin_types+10272> "basic_string:: _S_construct null not valid") at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/src/c++11/functexcept.cc:66 [...] On 64-bit Cygwin, however, I got the behavior reported by the OP: gdb: unknown target exception 0x20474343 at 0x7ff8cccca719 Thread 1 "exception_test" received signal ?, Unknown signal. 0x00007ff8cccca719 in RaiseException () from /c/WINDOWS/System32/KERNELBASE.dll (gdb) c Continuing. [Thread 4508.0x3e20 exited with code 541541187] [Thread 4508.0x5bc exited with code 541541187] [Thread 4508.0x5ee8 exited with code 541541187] [Thread 4508.0x1cd0 exited with code 541541187] [Inferior 1 (process 4508) exited with code 04021641503] Note that the breakpoint at 'terminate' is not reached. I tried putting a breakpoint at __cxa_throw and stepping through from there, but I don't really understand what's going on. Someone who knows the innards of exception handling will have to look at this. Ken ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: unhandled C++ exceptions not propagating 2020-08-16 14:56 ` Ken Brown @ 2020-08-16 22:38 ` Ken Brown 2020-08-17 17:36 ` [Attn: gcc maintainers] " Ken Brown 0 siblings, 1 reply; 17+ messages in thread From: Ken Brown @ 2020-08-16 22:38 UTC (permalink / raw) To: cygwin; +Cc: David McFarland On 8/16/2020 10:56 AM, Ken Brown via Cygwin wrote: > On 8/16/2020 9:52 AM, Takashi Yano via Cygwin wrote: >> On Sun, 16 Aug 2020 09:21:24 -0400 >> Ken Brown via Cygwin <cygwin@cygwin.com> wrote: >>> On 8/15/2020 11:53 PM, Takashi Yano via Cygwin wrote: >>>> On Sat, 15 Aug 2020 20:38:01 -0300 >>>> David McFarland via Cygwin <cygwin@cygwin.com> wrote: >>>>> >>>>> I was just debugging a c++ app (b2 build system from boost), and noticed >>>>> that it would appear to exit unexpectedly without an error. This turned >>>>> out to be when an unhandled C++ exception was thrown. >>>>> >>>>> On a fresh install of cygwin with gcc-g++, this program will throw an >>>>> exception from the std::string constructor: >>>>> >>>>> c++ -x c++ - <<END >>>>> #include <string> >>>>> int main() { std::string str(nullptr); return 0; } >>>>> END >>>>> >>>>> When it's executed from the shell it returns zero, but execution stops >>>>> at the exception. >>>>> >>>>> $ ./a; echo $? >>>>> 0 >>>>> >>>>> When executed under gdb, the exception is caught, and the process exits >>>>> non-zero when continued: >>>>> >>>>> (gdb) r >>>>> Starting program: /home/corngood/a >>>>> [New Thread 4300.0x1390] >>>>> [New Thread 4300.0x1d24] >>>>> [New Thread 4300.0x1d48] >>>>> [New Thread 4300.0x80c] >>>>> gdb: unknown target exception 0x20474343 at 0x7ff8d2cfa799 >>>>> Thread 1 "a" received signal ?, Unknown signal. >>>>> 0x00007ff8d2cfa799 in RaiseException () from >>>>> /cygdrive/c/WINDOWS/System32/KERNELBASE.dll >>>>> (gdb) c >>>>> Continuing. >>>>> [Thread 4300.0x1d24 exited with code 541541187] >>>>> [Thread 4300.0x1870 exited with code 541541187] >>>>> [Thread 4300.0x1d48 exited with code 541541187] >>>>> [Thread 4300.0x1390 exited with code 541541187] >>>>> [Inferior 1 (process 4300) exited with code 04021641503] >>>>> (gdb) >>>>> >>>>> When executed under strace, it exits with an error as expected: >>>>> >>>>> $ strace -o /dev/null a; echo $? >>>>> 67 >>>>> >>>>> That's as far as I've investigated so far. >>>> >>>> Is this the same issue with >>>> https://cygwin.com/pipermail/cygwin/2019-October/242795.html ? >>>> >>>> As far as I tested, this does not occur in 32-bit cygwin. >>> >>> This doesn't seem to be a new issue. I found the following report from 6 years >>> ago, on Cygwin 1.7.30 with GCC 4.9.0: >>> >>> https://stackoverflow.com/questions/24402412/program-executed-on-cygwin-does-not-report-a-thrown-exception >>> >> >> Thanks for the information. But I still wonder why 32-bit and 64-bit >> cygwin behave differently. > > I'm no C++ expert, but my understanding after a brief internet search is that an > uncaught exception is supposed to cause std::terminate to be called. So I > installed gcc-debuginfo and ran the OP's test case under gdb with a breakpoint > at 'terminate'. On 32-bit Cygwin I got the expected behavior: > > Thread 1 "exception_test" hit Breakpoint 1, std::terminate () > at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/eh_terminate.cc:96 > 96 __atomic_load (&__terminate_handler, &func, __ATOMIC_ACQUIRE); > (gdb) bt > #0 std::terminate () > at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/eh_terminate.cc:96 > #1 0x57c45909 in __cxxabiv1::__cxa_throw (obj=obj@entry=0x800396e8, > tinfo=tinfo@entry=0x57c646a8 <typeinfo for std::logic_error>, > dest=0x57be6c60 <std::logic_error::~logic_error()>) > at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/eh_throw.cc:95 > #2 0x57c49223 in std::__throw_logic_error ( > __s=__s@entry=0x57c60160 <cplus_demangle_builtin_types+10272> "basic_string:: > _S_construct null not valid") > at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/src/c++11/functexcept.cc:66 > [...] > > On 64-bit Cygwin, however, I got the behavior reported by the OP: > > gdb: unknown target exception 0x20474343 at 0x7ff8cccca719 > > Thread 1 "exception_test" received signal ?, Unknown signal. > 0x00007ff8cccca719 in RaiseException () from /c/WINDOWS/System32/KERNELBASE.dll > (gdb) c > Continuing. > [Thread 4508.0x3e20 exited with code 541541187] > [Thread 4508.0x5bc exited with code 541541187] > [Thread 4508.0x5ee8 exited with code 541541187] > [Thread 4508.0x1cd0 exited with code 541541187] > [Inferior 1 (process 4508) exited with code 04021641503] > > Note that the breakpoint at 'terminate' is not reached. I tried putting a > breakpoint at __cxa_throw and stepping through from there, but I don't really > understand what's going on. Someone who knows the innards of exception handling > will have to look at this. One further comment, and then I'll shut up and leave it to people who know what they're talking about: In the 64-bit case, the function _Unwind_RaiseException in libgcc/unwind-seh.c gets called, and it calls the Win32 function RaiseException as follows: RaiseException (STATUS_GCC_THROW, 0, 1, (ULONG_PTR *)&exc); Then the following comment appears: /* The exception handler installed in crt0 will continue any GCC exception that reaches there (and isn't marked non-continuable). Returning allows the C++ runtime to call std::terminate. */ Apparently this doesn't actually happen. Ken ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating 2020-08-16 22:38 ` Ken Brown @ 2020-08-17 17:36 ` Ken Brown 2020-08-17 18:13 ` Corinna Vinschen 0 siblings, 1 reply; 17+ messages in thread From: Ken Brown @ 2020-08-17 17:36 UTC (permalink / raw) To: cygwin On 8/16/2020 6:38 PM, Ken Brown via Cygwin wrote: > On 8/16/2020 10:56 AM, Ken Brown via Cygwin wrote: >> On 8/16/2020 9:52 AM, Takashi Yano via Cygwin wrote: >>> On Sun, 16 Aug 2020 09:21:24 -0400 >>> Ken Brown via Cygwin <cygwin@cygwin.com> wrote: >>>> On 8/15/2020 11:53 PM, Takashi Yano via Cygwin wrote: >>>>> On Sat, 15 Aug 2020 20:38:01 -0300 >>>>> David McFarland via Cygwin <cygwin@cygwin.com> wrote: >>>>>> >>>>>> I was just debugging a c++ app (b2 build system from boost), and noticed >>>>>> that it would appear to exit unexpectedly without an error. This turned >>>>>> out to be when an unhandled C++ exception was thrown. >>>>>> >>>>>> On a fresh install of cygwin with gcc-g++, this program will throw an >>>>>> exception from the std::string constructor: >>>>>> >>>>>> c++ -x c++ - <<END >>>>>> #include <string> >>>>>> int main() { std::string str(nullptr); return 0; } >>>>>> END >>>>>> >>>>>> When it's executed from the shell it returns zero, but execution stops >>>>>> at the exception. >>>>>> >>>>>> $ ./a; echo $? >>>>>> 0 >>>>>> >>>>>> When executed under gdb, the exception is caught, and the process exits >>>>>> non-zero when continued: >>>>>> >>>>>> (gdb) r >>>>>> Starting program: /home/corngood/a >>>>>> [New Thread 4300.0x1390] >>>>>> [New Thread 4300.0x1d24] >>>>>> [New Thread 4300.0x1d48] >>>>>> [New Thread 4300.0x80c] >>>>>> gdb: unknown target exception 0x20474343 at 0x7ff8d2cfa799 >>>>>> Thread 1 "a" received signal ?, Unknown signal. >>>>>> 0x00007ff8d2cfa799 in RaiseException () from >>>>>> /cygdrive/c/WINDOWS/System32/KERNELBASE.dll >>>>>> (gdb) c >>>>>> Continuing. >>>>>> [Thread 4300.0x1d24 exited with code 541541187] >>>>>> [Thread 4300.0x1870 exited with code 541541187] >>>>>> [Thread 4300.0x1d48 exited with code 541541187] >>>>>> [Thread 4300.0x1390 exited with code 541541187] >>>>>> [Inferior 1 (process 4300) exited with code 04021641503] >>>>>> (gdb) >>>>>> >>>>>> When executed under strace, it exits with an error as expected: >>>>>> >>>>>> $ strace -o /dev/null a; echo $? >>>>>> 67 >>>>>> >>>>>> That's as far as I've investigated so far. >>>>> >>>>> Is this the same issue with >>>>> https://cygwin.com/pipermail/cygwin/2019-October/242795.html ? >>>>> >>>>> As far as I tested, this does not occur in 32-bit cygwin. >>>> >>>> This doesn't seem to be a new issue. I found the following report from 6 years >>>> ago, on Cygwin 1.7.30 with GCC 4.9.0: >>>> >>>> https://stackoverflow.com/questions/24402412/program-executed-on-cygwin-does-not-report-a-thrown-exception >>>> >>> >>> Thanks for the information. But I still wonder why 32-bit and 64-bit >>> cygwin behave differently. >> >> I'm no C++ expert, but my understanding after a brief internet search is that >> an uncaught exception is supposed to cause std::terminate to be called. So I >> installed gcc-debuginfo and ran the OP's test case under gdb with a breakpoint >> at 'terminate'. On 32-bit Cygwin I got the expected behavior: >> >> Thread 1 "exception_test" hit Breakpoint 1, std::terminate () >> at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/eh_terminate.cc:96 >> 96 __atomic_load (&__terminate_handler, &func, __ATOMIC_ACQUIRE); >> (gdb) bt >> #0 std::terminate () >> at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/eh_terminate.cc:96 >> #1 0x57c45909 in __cxxabiv1::__cxa_throw (obj=obj@entry=0x800396e8, >> tinfo=tinfo@entry=0x57c646a8 <typeinfo for std::logic_error>, >> dest=0x57be6c60 <std::logic_error::~logic_error()>) >> at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/eh_throw.cc:95 >> #2 0x57c49223 in std::__throw_logic_error ( >> __s=__s@entry=0x57c60160 <cplus_demangle_builtin_types+10272> >> "basic_string:: >> _S_construct null not valid") >> at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/src/c++11/functexcept.cc:66 >> [...] >> >> On 64-bit Cygwin, however, I got the behavior reported by the OP: >> >> gdb: unknown target exception 0x20474343 at 0x7ff8cccca719 >> >> Thread 1 "exception_test" received signal ?, Unknown signal. >> 0x00007ff8cccca719 in RaiseException () from /c/WINDOWS/System32/KERNELBASE.dll >> (gdb) c >> Continuing. >> [Thread 4508.0x3e20 exited with code 541541187] >> [Thread 4508.0x5bc exited with code 541541187] >> [Thread 4508.0x5ee8 exited with code 541541187] >> [Thread 4508.0x1cd0 exited with code 541541187] >> [Inferior 1 (process 4508) exited with code 04021641503] >> >> Note that the breakpoint at 'terminate' is not reached. I tried putting a >> breakpoint at __cxa_throw and stepping through from there, but I don't really >> understand what's going on. Someone who knows the innards of exception >> handling will have to look at this. > > One further comment, and then I'll shut up I lied. > and leave it to people who know what > they're talking about: In the 64-bit case, the function _Unwind_RaiseException > in libgcc/unwind-seh.c gets called, and it calls the Win32 function > RaiseException as follows: > > RaiseException (STATUS_GCC_THROW, 0, 1, (ULONG_PTR *)&exc); > > Then the following comment appears: > > /* The exception handler installed in crt0 will continue any GCC > exception that reaches there (and isn't marked non-continuable). > Returning allows the C++ runtime to call std::terminate. */ > > Apparently this doesn't actually happen. I'm beginning to think this is a bug in the Cygwin build of gcc. The file unwind-seh.c is compiled on 64-bit Cygwin because __SEH__ is defined. But it makes assumptions, such as those in the comment quoted above, that are not valid on Cygwin. In fact, if you look at the main exception handler on Cygwin (exceptions.cc:626), it is clear that the exception code STATUS_GCC_THROW does not lead to continuation. It falls under the default case: default: /* If we don't recognize the exception, we have to assume that we are doing structured exception handling, and we let something else handle it. */ return ExceptionContinueSearch; [STATUS_GCC_THROW is 0x20474343, which shows up in the gdb output above as an unknown target exception.] So it seems to me that either Cygwin's exception handler has to learn to handle the exception codes defined in unwind-seh.c, or else gcc should be built with __SEH__ undefined. JonY, Achim, Corinna, am I missing something? Ken ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating 2020-08-17 17:36 ` [Attn: gcc maintainers] " Ken Brown @ 2020-08-17 18:13 ` Corinna Vinschen 2020-08-17 18:44 ` Achim Gratz 2020-08-17 19:06 ` Ken Brown 0 siblings, 2 replies; 17+ messages in thread From: Corinna Vinschen @ 2020-08-17 18:13 UTC (permalink / raw) To: cygwin On Aug 17 13:36, Ken Brown via Cygwin wrote: > On 8/16/2020 6:38 PM, Ken Brown via Cygwin wrote: > > One further comment, and then I'll shut up > > I lied. ...which is ok. > > and leave it to people who know what they're talking about: In the > > 64-bit case, the function _Unwind_RaiseException in libgcc/unwind-seh.c > > gets called, and it calls the Win32 function RaiseException as follows: > > > > RaiseException (STATUS_GCC_THROW, 0, 1, (ULONG_PTR *)&exc); > > > > Then the following comment appears: > > > > /* The exception handler installed in crt0 will continue any GCC > > exception that reaches there (and isn't marked non-continuable). > > Returning allows the C++ runtime to call std::terminate. */ > > > > Apparently this doesn't actually happen. > > I'm beginning to think this is a bug in the Cygwin build of gcc. The file > unwind-seh.c is compiled on 64-bit Cygwin because __SEH__ is defined. But > it makes assumptions, such as those in the comment quoted above, that are > not valid on Cygwin. > > In fact, if you look at the main exception handler on Cygwin > (exceptions.cc:626), it is clear that the exception code STATUS_GCC_THROW > does not lead to continuation. It falls under the default case: > > default: > /* If we don't recognize the exception, we have to assume that > we are doing structured exception handling, and we let > something else handle it. */ > return ExceptionContinueSearch; > > [STATUS_GCC_THROW is 0x20474343, which shows up in the gdb output above as > an unknown target exception.] > > So it seems to me that either Cygwin's exception handler has to learn to > handle the exception codes defined in unwind-seh.c, or else gcc should be > built with __SEH__ undefined. > > JonY, Achim, Corinna, am I missing something? This stuff isn't really my strong point. IIUC the above comment correctly, we might get away with adding another case to the exception handler switch: #define STATUS_GCC_THROW 0x20474343 case STATUS_GCC_THROW: return ExceptionContinueExecution; Did you try that, by any chance? Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating 2020-08-17 18:13 ` Corinna Vinschen @ 2020-08-17 18:44 ` Achim Gratz 2020-08-17 19:06 ` Ken Brown 1 sibling, 0 replies; 17+ messages in thread From: Achim Gratz @ 2020-08-17 18:44 UTC (permalink / raw) To: cygwin Corinna Vinschen writes: > This stuff isn't really my strong point. IIUC the above comment correctly, > we might get away with adding another case to the exception handler switch: > > #define STATUS_GCC_THROW 0x20474343 > case STATUS_GCC_THROW: > return ExceptionContinueExecution; > > Did you try that, by any chance? There is a clear expectation that SEH is available on 64bit as expressed in cygming.h from gcc (but not on 32bit, which explains why there's no problem there): #define TARGET_SEH (TARGET_64BIT_MS_ABI && flag_unwind_tables) and MS_ABI is the default for 64bit, flag_unwind_tables is a global variable that is set to 1 by default and very few platforms set it to 0. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating 2020-08-17 18:13 ` Corinna Vinschen 2020-08-17 18:44 ` Achim Gratz @ 2020-08-17 19:06 ` Ken Brown 2020-08-17 20:40 ` Ken Brown 1 sibling, 1 reply; 17+ messages in thread From: Ken Brown @ 2020-08-17 19:06 UTC (permalink / raw) To: cygwin On 8/17/2020 2:13 PM, Corinna Vinschen wrote: > On Aug 17 13:36, Ken Brown via Cygwin wrote: >> On 8/16/2020 6:38 PM, Ken Brown via Cygwin wrote: >>> One further comment, and then I'll shut up >> >> I lied. > > ...which is ok. > >>> and leave it to people who know what they're talking about: In the >>> 64-bit case, the function _Unwind_RaiseException in libgcc/unwind-seh.c >>> gets called, and it calls the Win32 function RaiseException as follows: >>> >>> RaiseException (STATUS_GCC_THROW, 0, 1, (ULONG_PTR *)&exc); >>> >>> Then the following comment appears: >>> >>> /* The exception handler installed in crt0 will continue any GCC >>> exception that reaches there (and isn't marked non-continuable). >>> Returning allows the C++ runtime to call std::terminate. */ >>> >>> Apparently this doesn't actually happen. >> >> I'm beginning to think this is a bug in the Cygwin build of gcc. The file >> unwind-seh.c is compiled on 64-bit Cygwin because __SEH__ is defined. But >> it makes assumptions, such as those in the comment quoted above, that are >> not valid on Cygwin. >> >> In fact, if you look at the main exception handler on Cygwin >> (exceptions.cc:626), it is clear that the exception code STATUS_GCC_THROW >> does not lead to continuation. It falls under the default case: >> >> default: >> /* If we don't recognize the exception, we have to assume that >> we are doing structured exception handling, and we let >> something else handle it. */ >> return ExceptionContinueSearch; >> >> [STATUS_GCC_THROW is 0x20474343, which shows up in the gdb output above as >> an unknown target exception.] >> >> So it seems to me that either Cygwin's exception handler has to learn to >> handle the exception codes defined in unwind-seh.c, or else gcc should be >> built with __SEH__ undefined. >> >> JonY, Achim, Corinna, am I missing something? > > This stuff isn't really my strong point. IIUC the above comment correctly, > we might get away with adding another case to the exception handler switch: > > #define STATUS_GCC_THROW 0x20474343 > case STATUS_GCC_THROW: > return ExceptionContinueExecution; > > Did you try that, by any chance? No, I didn't. It might well solve the immediate problem of this bug report. But then there are two other exception codes that occur in unwind-seh.c that we would also have to deal with: STATUS_GCC_UNWIND and STATUS_GCC_FORCED. Someone would have to look at their uses and figure out what, if anything, Cygwin should do with them. I'd be willing to take a crack at this if no one more knowledgeable steps forward. But keep in mind that I've never looked at the gcc code or Cygwin's exception handler until today, so I'm not necessarily the best person to do this. Ken ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating 2020-08-17 19:06 ` Ken Brown @ 2020-08-17 20:40 ` Ken Brown 2020-08-17 20:50 ` Ken Brown 0 siblings, 1 reply; 17+ messages in thread From: Ken Brown @ 2020-08-17 20:40 UTC (permalink / raw) To: cygwin On 8/17/2020 3:06 PM, Ken Brown via Cygwin wrote: > On 8/17/2020 2:13 PM, Corinna Vinschen wrote: >> On Aug 17 13:36, Ken Brown via Cygwin wrote: >>> On 8/16/2020 6:38 PM, Ken Brown via Cygwin wrote: >>>> One further comment, and then I'll shut up >>> >>> I lied. >> >> ...which is ok. >> >>>> and leave it to people who know what they're talking about: In the >>>> 64-bit case, the function _Unwind_RaiseException in libgcc/unwind-seh.c >>>> gets called, and it calls the Win32 function RaiseException as follows: >>>> >>>> RaiseException (STATUS_GCC_THROW, 0, 1, (ULONG_PTR *)&exc); >>>> >>>> Then the following comment appears: >>>> >>>> /* The exception handler installed in crt0 will continue any GCC >>>> exception that reaches there (and isn't marked non-continuable). >>>> Returning allows the C++ runtime to call std::terminate. */ >>>> >>>> Apparently this doesn't actually happen. >>> >>> I'm beginning to think this is a bug in the Cygwin build of gcc. The file >>> unwind-seh.c is compiled on 64-bit Cygwin because __SEH__ is defined. But >>> it makes assumptions, such as those in the comment quoted above, that are >>> not valid on Cygwin. >>> >>> In fact, if you look at the main exception handler on Cygwin >>> (exceptions.cc:626), it is clear that the exception code STATUS_GCC_THROW >>> does not lead to continuation. It falls under the default case: >>> >>> default: >>> /* If we don't recognize the exception, we have to assume that >>> we are doing structured exception handling, and we let >>> something else handle it. */ >>> return ExceptionContinueSearch; >>> >>> [STATUS_GCC_THROW is 0x20474343, which shows up in the gdb output above as >>> an unknown target exception.] >>> >>> So it seems to me that either Cygwin's exception handler has to learn to >>> handle the exception codes defined in unwind-seh.c, or else gcc should be >>> built with __SEH__ undefined. >>> >>> JonY, Achim, Corinna, am I missing something? >> >> This stuff isn't really my strong point. IIUC the above comment correctly, >> we might get away with adding another case to the exception handler switch: >> >> #define STATUS_GCC_THROW 0x20474343 >> case STATUS_GCC_THROW: >> return ExceptionContinueExecution; >> >> Did you try that, by any chance? > > No, I didn't. It might well solve the immediate problem of this bug report. But > then there are two other exception codes that occur in unwind-seh.c that we > would also have to deal with: STATUS_GCC_UNWIND and STATUS_GCC_FORCED. > Someone would have to look at their uses and figure out what, if anything, > Cygwin should do with them. This isn't an issue after all. The comment I quoted above refers to all GCC exceptions, not just STATUS_GCC_THROW. I'll submit a patch after testing. Ken ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating 2020-08-17 20:40 ` Ken Brown @ 2020-08-17 20:50 ` Ken Brown 2020-08-18 0:09 ` JonY 0 siblings, 1 reply; 17+ messages in thread From: Ken Brown @ 2020-08-17 20:50 UTC (permalink / raw) To: cygwin; +Cc: David McFarland On 8/17/2020 4:40 PM, Ken Brown via Cygwin wrote: > On 8/17/2020 3:06 PM, Ken Brown via Cygwin wrote: >> On 8/17/2020 2:13 PM, Corinna Vinschen wrote: >>> On Aug 17 13:36, Ken Brown via Cygwin wrote: >>>> On 8/16/2020 6:38 PM, Ken Brown via Cygwin wrote: >>>>> One further comment, and then I'll shut up >>>> >>>> I lied. >>> >>> ...which is ok. >>> >>>>> and leave it to people who know what they're talking about: In the >>>>> 64-bit case, the function _Unwind_RaiseException in libgcc/unwind-seh.c >>>>> gets called, and it calls the Win32 function RaiseException as follows: >>>>> >>>>> RaiseException (STATUS_GCC_THROW, 0, 1, (ULONG_PTR *)&exc); >>>>> >>>>> Then the following comment appears: >>>>> >>>>> /* The exception handler installed in crt0 will continue any GCC >>>>> exception that reaches there (and isn't marked non-continuable). >>>>> Returning allows the C++ runtime to call std::terminate. */ >>>>> >>>>> Apparently this doesn't actually happen. >>>> >>>> I'm beginning to think this is a bug in the Cygwin build of gcc. The file >>>> unwind-seh.c is compiled on 64-bit Cygwin because __SEH__ is defined. But >>>> it makes assumptions, such as those in the comment quoted above, that are >>>> not valid on Cygwin. >>>> >>>> In fact, if you look at the main exception handler on Cygwin >>>> (exceptions.cc:626), it is clear that the exception code STATUS_GCC_THROW >>>> does not lead to continuation. It falls under the default case: >>>> >>>> default: >>>> /* If we don't recognize the exception, we have to assume that >>>> we are doing structured exception handling, and we let >>>> something else handle it. */ >>>> return ExceptionContinueSearch; >>>> >>>> [STATUS_GCC_THROW is 0x20474343, which shows up in the gdb output above as >>>> an unknown target exception.] >>>> >>>> So it seems to me that either Cygwin's exception handler has to learn to >>>> handle the exception codes defined in unwind-seh.c, or else gcc should be >>>> built with __SEH__ undefined. >>>> >>>> JonY, Achim, Corinna, am I missing something? >>> >>> This stuff isn't really my strong point. IIUC the above comment correctly, >>> we might get away with adding another case to the exception handler switch: >>> >>> #define STATUS_GCC_THROW 0x20474343 >>> case STATUS_GCC_THROW: >>> return ExceptionContinueExecution; >>> >>> Did you try that, by any chance? >> >> No, I didn't. It might well solve the immediate problem of this bug report. >> But then there are two other exception codes that occur in unwind-seh.c that >> we would also have to deal with: STATUS_GCC_UNWIND and STATUS_GCC_FORCED. >> Someone would have to look at their uses and figure out what, if anything, >> Cygwin should do with them. > > This isn't an issue after all. The comment I quoted above refers to all GCC > exceptions, not just STATUS_GCC_THROW. I'll submit a patch after testing. I've sent the patch. The output of the OP's test case is now the same on 64-bit as on 32-bit: $ ./a terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_S_construct null not valid Aborted (core dumped) Ken ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating 2020-08-17 20:50 ` Ken Brown @ 2020-08-18 0:09 ` JonY 2020-08-18 0:20 ` Ken Brown 0 siblings, 1 reply; 17+ messages in thread From: JonY @ 2020-08-18 0:09 UTC (permalink / raw) To: cygwin [-- Attachment #1.1: Type: text/plain, Size: 550 bytes --] On 8/17/20 8:50 PM, Ken Brown via Cygwin wrote: >> >> This isn't an issue after all. The comment I quoted above refers to >> all GCC exceptions, not just STATUS_GCC_THROW. I'll submit a patch >> after testing. > > I've sent the patch. The output of the OP's test case is now the same > on 64-bit as on 32-bit: > > $ ./a > terminate called after throwing an instance of 'std::logic_error' > what(): basic_string::_S_construct null not valid > Aborted (core dumped) > Is the patch on gcc-patches? I'm not seeing it somehow. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating 2020-08-18 0:09 ` JonY @ 2020-08-18 0:20 ` Ken Brown 2020-08-18 1:46 ` JonY 0 siblings, 1 reply; 17+ messages in thread From: Ken Brown @ 2020-08-18 0:20 UTC (permalink / raw) To: cygwin On 8/17/2020 8:09 PM, JonY via Cygwin wrote: > On 8/17/20 8:50 PM, Ken Brown via Cygwin wrote: >>> >>> This isn't an issue after all. The comment I quoted above refers to >>> all GCC exceptions, not just STATUS_GCC_THROW. I'll submit a patch >>> after testing. >> >> I've sent the patch. The output of the OP's test case is now the same >> on 64-bit as on 32-bit: >> >> $ ./a >> terminate called after throwing an instance of 'std::logic_error' >> what(): basic_string::_S_construct null not valid >> Aborted (core dumped) >> > > Is the patch on gcc-patches? I'm not seeing it somehow. No, it's on cygwin-patches. Ken ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating 2020-08-18 0:20 ` Ken Brown @ 2020-08-18 1:46 ` JonY 0 siblings, 0 replies; 17+ messages in thread From: JonY @ 2020-08-18 1:46 UTC (permalink / raw) To: cygwin [-- Attachment #1.1: Type: text/plain, Size: 755 bytes --] On 8/18/20 12:20 AM, Ken Brown via Cygwin wrote: > On 8/17/2020 8:09 PM, JonY via Cygwin wrote: >> On 8/17/20 8:50 PM, Ken Brown via Cygwin wrote: >>>> >>>> This isn't an issue after all. The comment I quoted above refers to >>>> all GCC exceptions, not just STATUS_GCC_THROW. I'll submit a patch >>>> after testing. >>> >>> I've sent the patch. The output of the OP's test case is now the same >>> on 64-bit as on 32-bit: >>> >>> $ ./a >>> terminate called after throwing an instance of 'std::logic_error' >>> what(): basic_string::_S_construct null not valid >>> Aborted (core dumped) >>> >> >> Is the patch on gcc-patches? I'm not seeing it somehow. > > No, it's on cygwin-patches. > OK thanks for working on this. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: unhandled C++ exceptions not propagating 2020-08-16 3:53 ` Takashi Yano 2020-08-16 13:21 ` Ken Brown @ 2020-08-16 14:17 ` David McFarland 1 sibling, 0 replies; 17+ messages in thread From: David McFarland @ 2020-08-16 14:17 UTC (permalink / raw) To: Takashi Yano; +Cc: cygwin Takashi Yano <takashi.yano@nifty.ne.jp> writes: > On Sat, 15 Aug 2020 20:38:01 -0300 > David McFarland via Cygwin <cygwin@cygwin.com> wrote: >> >> I was just debugging a c++ app (b2 build system from boost), and noticed >> that it would appear to exit unexpectedly without an error. This turned >> out to be when an unhandled C++ exception was thrown. >> >> On a fresh install of cygwin with gcc-g++, this program will throw an >> exception from the std::string constructor: >> >> c++ -x c++ - <<END >> #include <string> >> int main() { std::string str(nullptr); return 0; } >> END >> >> When it's executed from the shell it returns zero, but execution stops >> at the exception. >> >> $ ./a; echo $? >> 0 >> >> When executed under gdb, the exception is caught, and the process exits >> non-zero when continued: >> >> (gdb) r >> Starting program: /home/corngood/a >> [New Thread 4300.0x1390] >> [New Thread 4300.0x1d24] >> [New Thread 4300.0x1d48] >> [New Thread 4300.0x80c] >> gdb: unknown target exception 0x20474343 at 0x7ff8d2cfa799 >> Thread 1 "a" received signal ?, Unknown signal. >> 0x00007ff8d2cfa799 in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll >> (gdb) c >> Continuing. >> [Thread 4300.0x1d24 exited with code 541541187] >> [Thread 4300.0x1870 exited with code 541541187] >> [Thread 4300.0x1d48 exited with code 541541187] >> [Thread 4300.0x1390 exited with code 541541187] >> [Inferior 1 (process 4300) exited with code 04021641503] >> (gdb) >> >> When executed under strace, it exits with an error as expected: >> >> $ strace -o /dev/null a; echo $? >> 67 >> >> That's as far as I've investigated so far. > > Is this the same issue with > https://cygwin.com/pipermail/cygwin/2019-October/242795.html ? > > As far as I tested, this does not occur in 32-bit cygwin. Yeah, it seems to be. Thanks for tracking that down. I tried using ProcessMonitor, and when I run the test program from a shell (where it appears to return 0) I get: a.exe 7096 Process Exit SUCCESS Exit Status: 541541187, User Time: 0.0000000 seconds, Kernel Time: 0.0000000 seconds, Private Bytes: 4,661,248, Peak Private Bytes: 4,661,248, Working Set: 4,255,744, Peak Working Set: 4,259,840 So the win32 process does appear to be exiting non-zero. Did you find out anything else when you investigated it? My next step was going to be digging into why it behaves differently under strace. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2020-08-18 1:46 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-08-15 23:38 unhandled C++ exceptions not propagating David McFarland 2020-08-16 3:25 ` JonY 2020-08-16 3:53 ` Takashi Yano 2020-08-16 13:21 ` Ken Brown 2020-08-16 13:52 ` Takashi Yano 2020-08-16 14:56 ` Ken Brown 2020-08-16 22:38 ` Ken Brown 2020-08-17 17:36 ` [Attn: gcc maintainers] " Ken Brown 2020-08-17 18:13 ` Corinna Vinschen 2020-08-17 18:44 ` Achim Gratz 2020-08-17 19:06 ` Ken Brown 2020-08-17 20:40 ` Ken Brown 2020-08-17 20:50 ` Ken Brown 2020-08-18 0:09 ` JonY 2020-08-18 0:20 ` Ken Brown 2020-08-18 1:46 ` JonY 2020-08-16 14:17 ` David McFarland
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).