View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000438 | GCC - GNU C Compiler | Bug | public | 2010-08-20 07:22 | 2020-08-24 03:08 |
| Reporter | komh | Assigned To | psmedley | ||
| Priority | immediate | Severity | block | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Summary | 0000438: Exception 'throw' in 'try' block causes SIGABRT without being processed by 'catch' block | ||||
| Description | Hi/2. I've seemed to encounter an exception bug. The 'catch' block of the attached codes does not work. EMX and kLIBC 3.3.5 works as expected. But gcc 4.3.x and 4.4.x terminated with SIGABRT as the following. ----- terminate called after throwing an instance of 'char const*' terminate called recursively Killed by SIGABRT pid=0x035c ppid=0x0357 tid=0x0001 slot=0x00b2 pri=0x0200 mc=0x0001 F:\LANG\WORK\TEST\XS.EXE Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it. ----- Instead, you should see 'Catched exception = Throw exception!' on your screen. You can compile using g++ as the following. g++ xs.cpp | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
|
|
Ping ? |
|
|
I've had little to no free time recently, so haven't had a chance to look... are you able to test the code with a modern gcc version on another platform? |
|
|
The latest MAME use this feature in their driver model. When I reported this problem to them, they said they had no problem at all. And any other people than me did not report this problem at all. So I think, this is a OS/2 specific bug. |
|
|
Just ran into the same issue. Any news ? |
|
|
will hopefully find time to look at the problem during Christmas vacation - which starts December 17th |
|
|
Interestingly, when built with a build of gcc 4.5.0 I have here (unreleased) the behaviour KO expects does occur... |
|
|
Seems I accidentally fixed this in 4.5.0 When I apply my 4.4.5 patches to 4.5.1 - the bug re-appears - so I will try work out which patch changes the behaviour. |
|
|
OK I know how to fix this now.... The problem is that libc063.dll includes the gcc exception functions from GCC 3.3.5 These have obviously changed over time. Basically what needs to happen is I need to rebuilt GCC 4.4.5 with all the unwind functions found in libc063, and we need a new libc_dll.a/libc_dll.lib that doesn't include the unwind* functions. My local build of xs.cpp gcc 4.5.2 now works as expected: [U:\DEV]xs Catched exception = Throw exception! |
|
|
http://smedley.info/gcc-4.4.5-os2-20101220.zip has the fix. Note that \usr\local444\lib\libc_dll.a/.lib are included These are import libs for libc063 that do NOT include the various unwind* functions. These now come from gcc445.dll |
|
|
Note the included libc_dll.a doesn't include libsocket or libsyslog - need to work out how to append those to it.... |
|
|
Great!!! I could get a working SDLMAME. ^^ BTW, when I compile xs.cpp with -Zomf, xs.exe crashes at exit. But using WLINK as a OMF linker does not have this problem. This crash occurs only with all the IBM linker such as LINK386, VAC308 and VAC365. Is this a bug of IBM linker ? Or a new libc_dll.a/.lib ? |
|
|
The crashes is due to SIGSEGV. |
|
|
I only use wlink as linker here - haven't tried with ilink. I fail to see how the new libc_dll could cause this... |
|
|
btw there will be another update as I only excluded the unwind* functions from libc_dll.* - there are a bunch more libgcc functions that should be excluded. Rather than trying to bundle libsocket and libsyslog into libc_dll I'll likely modify the compiler to automatically link against these libraries - looking into this now |
|
|
Interestingly, try-catch works well with -Zomf using WLINK even if old gcc445. Hmm... |
|
|
very interesting - I see what you mean now about: g++ xs.cpp (works) g++ -Zomf xs.cpp (fails) |
|
|
Hi i just tried it... [O:\]g++ -Zomf xs.cpp [O:\]xs Catched exception = Throw exception! |
|
|
Fixed in 4.5.2 - an updated 4.4.5 will follow soon |
|
|
Do you have no plan to distribute gcc445 as well as gcc452 ? The reason why I prefer gcc445 to gcc452 is gcc445 does almost not generate emxomf warning. gcc452 generates massive warnings. Can I see a updated gcc445 ? ^^ |
|
|
For 4.4.5, you could try http://smedley.info/gcc-4.4.5-os2-20110122.zip and give me some feedback. Note that this needs an *updated* gcc445 so prepare for end users to contact you saying things don't work cos they can't read documentation. For the extra warnings from gcc 4.5.2 - make sure you have a fixed emxomf.exe in the path - that should prevent the link warnings |
|
|
Ok, I tested a updated gcc445 and gcc452. Both work well. But gcc452 generates massive warnings when using -Zomf, but gcc445 not as I said before. Of course, both use a fixed emxomf.exe. At least, this is not a problem of emxomf.exe. BTW, I tried to compile xs.cpp with gcc not g++ by mistake. Both gcc445 and gcc452 failed to compile it. The following is the error messages. ----- P:./cctEfUyB.o: Undefined symbol ___cxa_allocate_exception referenced from text segment P:./cctEfUyB.o: Undefined symbol typeinfo for char const* referenced from text segment P:./cctEfUyB.o: Undefined symbol ___cxa_throw referenced from text segment P:./cctEfUyB.o: Undefined symbol ___cxa_begin_catch referenced from text segment P:./cctEfUyB.o: Undefined symbol std::cout referenced from text segment P:./cctEfUyB.o: Undefined symbol std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) referenced from text segment P:./cctEfUyB.o: Undefined symbol std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) referenced from text segment P:./cctEfUyB.o: Undefined symbol std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&) referenced from text segment P:./cctEfUyB.o: Undefined symbol std::ostream::operator<<(std::ostream& (*)(std::ostream&)) referenced from text segment P:./cctEfUyB.o: Undefined symbol ___cxa_end_catch referenced from text segment P:./cctEfUyB.o: Undefined symbol ___cxa_end_catch referenced from text segment P:./cctEfUyB.o: Undefined symbol std::ios_base::Init::Init() referenced from text segment P:./cctEfUyB.o: Undefined symbol std::ios_base::Init::~Init() referenced from text segment P:./cctEfUyB.o: Undefined symbol typeinfo for char const* referenced from data segment P:./cctEfUyB.o: Undefined symbol ___gxx_personality_v0 referenced from data segment ----- Adding -lstdc++ -lm to the command line option fixes these errors. But, old gcc445 does not add -lstdc++ as new gcc445. Of course, gcc of it can compile with any problems. Is this a side effect of the solution for a exception problem ? Finally, Any users will not contact me due to gcc445.dll. Because I don't link anything against gcc445.dll at all. I prefer '-static-libgcc'. ^^ |
|
|
I tested gcc 4.5.2 (with Java) and must confirm that exceptions work again. I had a similar issue with SIGABRT (http://svn.netlabs.org/java/ticket/59) and now it is gone. Thanks for the fix. Regarding the missing stdc++ library when linking. The current behavior of gcc 4.5.2 (20101231) is actually the standard GCC behavior (that I've been always observing on Linux): if you use the gcc executable for linking, the C++ libraries are not automatically added to the link step; this is only done when you use the g++ executable. Which looks quite logical. It seems that the previous OS/2 versions of GCC had a hack that added libstdc++ even when gcc is called and in the latest release Paul somehow removed that hack (intentionally or by accident). Regarding -Zomf warnings. They come from emxomf.exe, really. For some reason, Paul included an older version of my patched emxomf while the newer one is available at http://svn.netlabs.org/libc/attachment/ticket/220/emxomf-2010-08-10.zip. This one has more fixes for those annoying warnings. |
|
|
Old gcc445 also does not add -lstdc++ at linking time. You can confirm it with '-v' option. But, the reason why gcc of it can compile .cpp is that libc_dll.a/lib has those functions. New gcc445 use a new libc_dll.a/lib to resolve a exception problem. And the new libc_dll.a/lib does not have those functions. So gcc of new gcc445 cannot link .cpp successfully. It's a side effect of the solution for the exception problem. Anyway since this behavior is common on cross-platform, I have no complains any more. ^^ And emxomf.exe. Of course, I also know that emxomf.exe is the cause. But what I would to say is that gcc445 and gcc452 generate some information in a different way. And emxomf.exe accepts the output of gcc445 without warnings but not of gcc452. As a result, I prefer gcc445. ^^ If emxomf.exe is fixed, it would be good. |
|
|
Yes, you're right. LIBCxxx.DLL actually contains (all?) these exports. Regarding emxomf.exe, are you sure you get the warnings with the one I posted a link to (2010-08-10)? I don't get any such warnings here. |
|
|
Wow, good. Your new emxomf.exe does not generate warnings at all at least when compiling and linking xs.cpp. Good job. ^^ |
|
|
Resolved in latest GCC builds |
|
|
gcc-4.8.2-os2-20131214 also fails. |
|
|
i can reproduce this with gcc 4.8.2, but unfortunately the cause is different |
|
|
Seems to work again in 4.8.3 - http://smedley.id.au/tmp/gcc-4.8.3-os2-20140704.zip |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-08-20 07:22 | komh | New Issue | |
| 2010-08-20 07:22 | komh | File Added: xs.cpp | |
| 2010-10-18 14:10 | komh | Note Added: 0001745 | |
| 2010-10-21 08:14 | psmedley | Note Added: 0001751 | |
| 2010-10-27 12:14 | komh | Note Added: 0001758 | |
| 2010-12-07 07:52 | rudi | Note Added: 0001770 | |
| 2010-12-07 08:10 | psmedley | Note Added: 0001771 | |
| 2010-12-07 08:23 | psmedley | Note Added: 0001772 | |
| 2010-12-09 05:26 | psmedley | Note Added: 0001773 | |
| 2010-12-20 01:08 | psmedley | Note Added: 0001776 | |
| 2010-12-20 04:13 | psmedley | Note Added: 0001777 | |
| 2010-12-20 04:13 | psmedley | Assigned To | => psmedley |
| 2010-12-20 04:13 | psmedley | Status | new => feedback |
| 2010-12-20 08:30 | psmedley | Note Added: 0001779 | |
| 2010-12-21 05:25 | komh | Note Added: 0001783 | |
| 2010-12-21 05:25 | komh | Status | feedback => assigned |
| 2010-12-21 05:26 | komh | Note Added: 0001784 | |
| 2010-12-21 06:10 | psmedley | Note Added: 0001785 | |
| 2010-12-21 06:11 | psmedley | Note Added: 0001786 | |
| 2010-12-21 13:35 | komh | Note Added: 0001787 | |
| 2010-12-26 03:56 | psmedley | Note Added: 0001788 | |
| 2010-12-26 10:50 | tellerbop | Note Added: 0001789 | |
| 2010-12-30 22:32 | psmedley | Note Added: 0001792 | |
| 2010-12-30 22:32 | psmedley | Status | assigned => closed |
| 2010-12-30 22:32 | psmedley | Resolution | open => fixed |
| 2011-02-06 10:43 | komh | Note Added: 0001827 | |
| 2011-02-06 10:43 | komh | Status | closed => feedback |
| 2011-02-06 10:43 | komh | Resolution | fixed => reopened |
| 2011-02-06 19:54 | psmedley | Note Added: 0001828 | |
| 2011-02-07 14:15 | komh | Note Added: 0001831 | |
| 2011-02-07 14:15 | komh | Status | feedback => assigned |
| 2011-03-02 11:16 | dmik | Note Added: 0001842 | |
| 2011-03-02 11:17 | dmik | Note Edited: 0001842 | |
| 2011-03-02 14:02 | komh | Note Added: 0001843 | |
| 2011-03-02 14:43 | dmik | Note Added: 0001844 | |
| 2011-03-03 12:02 | komh | Note Added: 0001845 | |
| 2011-04-22 23:20 | psmedley | Note Added: 0001897 | |
| 2011-04-22 23:20 | psmedley | Status | assigned => closed |
| 2011-04-22 23:20 | psmedley | Resolution | reopened => fixed |
| 2013-12-15 05:31 | komh | Note Added: 0002585 | |
| 2013-12-15 05:31 | komh | Status | closed => feedback |
| 2013-12-15 05:31 | komh | Resolution | fixed => reopened |
| 2013-12-15 08:14 | psmedley | Note Added: 0002586 | |
| 2014-07-04 09:44 | psmedley | Note Added: 0002780 | |
| 2014-07-04 09:44 | psmedley | Status | feedback => resolved |
| 2014-07-04 09:44 | psmedley | Resolution | reopened => fixed |
| 2020-08-24 03:08 | psmedley | Status | resolved => closed |
