View Issue Details

IDProjectCategoryView StatusLast Update
0000438GCC - GNU C CompilerBugpublic2014-07-04 19:14
ReporterkomhAssigned Topsmedley 
Status resolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0000438: Exception 'throw' in 'try' block causes SIGABRT without being processed by 'catch' block

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
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
TagsNo tags attached.



2010-08-20 16:52


xs.cpp (294 bytes)


2010-10-19 00:40

reporter   ~0001745

Ping ?


2010-10-21 18:44

administrator   ~0001751

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?


2010-10-27 22:44

reporter   ~0001758

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.


2010-12-07 18:22

reporter   ~0001770

Just ran into the same issue. Any news ?


2010-12-07 18:40

administrator   ~0001771

will hopefully find time to look at the problem during Christmas vacation - which starts December 17th


2010-12-07 18:53

administrator   ~0001772

Interestingly, when built with a build of gcc 4.5.0 I have here (unreleased) the behaviour KO expects does occur...


2010-12-09 15:56

administrator   ~0001773

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.


2010-12-20 11:38

administrator   ~0001776

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:
Catched exception = Throw exception!


2010-12-20 14:43

administrator   ~0001777 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


2010-12-20 19:00

administrator   ~0001779

Note the included libc_dll.a doesn't include libsocket or libsyslog - need to work out how to append those to it....


2010-12-21 15:55

reporter   ~0001783


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 ?


2010-12-21 15:56

reporter   ~0001784

The crashes is due to SIGSEGV.


2010-12-21 16:40

administrator   ~0001785

I only use wlink as linker here - haven't tried with ilink. I fail to see how the new libc_dll could cause this...


2010-12-21 16:41

administrator   ~0001786

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


2010-12-22 00:05

reporter   ~0001787

Interestingly, try-catch works well with -Zomf using WLINK even if old gcc445.



2010-12-26 14:26

administrator   ~0001788

very interesting - I see what you mean now about:
g++ xs.cpp (works)
g++ -Zomf xs.cpp (fails)


2010-12-26 21:20

reporter   ~0001789

Hi i just tried it...

[O:\]g++ -Zomf xs.cpp

Catched exception = Throw exception!


2010-12-31 09:02

administrator   ~0001792

Fixed in 4.5.2 - an updated 4.4.5 will follow soon


2011-02-06 21:13

reporter   ~0001827

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 ? ^^


2011-02-07 06:24

administrator   ~0001828

For 4.4.5, you could try 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


2011-02-08 00:45

reporter   ~0001831

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
P:./cctEfUyB.o: Undefined symbol ___cxa_throw referenced from text segment
P:./cctEfUyB.o: Undefined symbol ___cxa_begin_catch referenced from text
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
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
P:./cctEfUyB.o: Undefined symbol ___gxx_personality_v0 referenced from data

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'. ^^


2011-03-02 21:46

reporter   ~0001842

Last edited: 2011-03-02 21:47

View 2 revisions

I tested gcc 4.5.2 (with Java) and must confirm that exceptions work again. I had a similar issue with SIGABRT ( 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 This one has more fixes for those annoying warnings.


2011-03-03 00:32

reporter   ~0001843

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.


2011-03-03 01:13

reporter   ~0001844

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.


2011-03-03 22:32

reporter   ~0001845

Wow, good.

Your new emxomf.exe does not generate warnings at all at least when compiling and linking xs.cpp.

Good job. ^^


2011-04-23 08:50

administrator   ~0001897

Resolved in latest GCC builds


2013-12-15 16:01

reporter   ~0002585

gcc-4.8.2-os2-20131214 also fails.


2013-12-15 18:44

administrator   ~0002586

i can reproduce this with gcc 4.8.2, but unfortunately the cause is different


2014-07-04 19:14

administrator   ~0002780

Seems to work again in 4.8.3 -

Issue History

Date Modified Username Field Change
2010-08-20 16:52 komh New Issue
2010-08-20 16:52 komh File Added: xs.cpp
2010-10-19 00:40 komh Note Added: 0001745
2010-10-21 18:44 psmedley Note Added: 0001751
2010-10-27 22:44 komh Note Added: 0001758
2010-12-07 18:22 rudi Note Added: 0001770
2010-12-07 18:40 psmedley Note Added: 0001771
2010-12-07 18:53 psmedley Note Added: 0001772
2010-12-09 15:56 psmedley Note Added: 0001773
2010-12-20 11:38 psmedley Note Added: 0001776
2010-12-20 14:43 psmedley Note Added: 0001777
2010-12-20 14:43 psmedley Assigned To => psmedley
2010-12-20 14:43 psmedley Status new => feedback
2010-12-20 19:00 psmedley Note Added: 0001779
2010-12-21 15:55 komh Note Added: 0001783
2010-12-21 15:55 komh Status feedback => assigned
2010-12-21 15:56 komh Note Added: 0001784
2010-12-21 16:40 psmedley Note Added: 0001785
2010-12-21 16:41 psmedley Note Added: 0001786
2010-12-22 00:05 komh Note Added: 0001787
2010-12-26 14:26 psmedley Note Added: 0001788
2010-12-26 21:20 tellerbop Note Added: 0001789
2010-12-31 09:02 psmedley Note Added: 0001792
2010-12-31 09:02 psmedley Status assigned => closed
2010-12-31 09:02 psmedley Resolution open => fixed
2011-02-06 21:13 komh Note Added: 0001827
2011-02-06 21:13 komh Status closed => feedback
2011-02-06 21:13 komh Resolution fixed => reopened
2011-02-07 06:24 psmedley Note Added: 0001828
2011-02-08 00:45 komh Note Added: 0001831
2011-02-08 00:45 komh Status feedback => assigned
2011-03-02 21:46 dmik Note Added: 0001842
2011-03-02 21:47 dmik Note Edited: 0001842 View Revisions
2011-03-03 00:32 komh Note Added: 0001843
2011-03-03 01:13 dmik Note Added: 0001844
2011-03-03 22:32 komh Note Added: 0001845
2011-04-23 08:50 psmedley Note Added: 0001897
2011-04-23 08:50 psmedley Status assigned => closed
2011-04-23 08:50 psmedley Resolution reopened => fixed
2013-12-15 16:01 komh Note Added: 0002585
2013-12-15 16:01 komh Status closed => feedback
2013-12-15 16:01 komh Resolution fixed => reopened
2013-12-15 18:44 psmedley Note Added: 0002586
2014-07-04 19:14 psmedley Note Added: 0002780
2014-07-04 19:14 psmedley Status feedback => resolved
2014-07-04 19:14 psmedley Resolution reopened => fixed