Bug in shared library version of newlib's libstdc++.so?

Have a question about our Software Developer Kit? Ask them here.
Post Reply
User avatar
nexus
Beta Tester
Beta Tester
Posts: 347
Joined: Mon Dec 20, 2010 2:11 pm
Location: Germany

Bug in shared library version of newlib's libstdc++.so?

Post by nexus »

Ok, then. Thanks for this official AOS4 support forum and I take the opportunity
to rephrase my c++ problem with the SDK/Compiler/Linker, which I mentioned
earlier only at the temporarily amigans.net site.

I really hope some solution or fix can be found by the AOS4 dev team.
Thanks in advance for any helpful replies!


Here's the bug description:

It seems there's a problem with newlib, when throwing an error and linking
with the shared object version of libstdc++.so.

See the following simple code:

Code: Select all

#include <iostream>
using namespace std;

class DummyClass {
  public:
    DummyClass(){};	 
};

int main( int32_t argc, char** argv ){
  DummyClass dc;

  try{
    cout<<"throw error"<<endl;
    throw dc;
  /*}catch(DummyClass dcr){*/ // same problem occurs when used instead of the next  line 
  }catch(DummyClass &dcr)
     cout<<"Dummy error!"<<endl;
  }catch(...){
     cout<<"Unknown error"<<endl;
  }
  return 0;
}                
Compiling and statically linking by

"g++ Main.cpp -o test"

gives you a binary called "test" which outputs correctly
"Dummy error!" to stdout.

When compiling and linking with libc.so:

g++ -use-dynld Main.cpp -o test"

Then "test" causes a GripReaper:

Code: Select all

Stack trace:
		libstdc++.so:_Z16get_adjusted_ptrPKSt9type_infoS1_PPv()+0x28 (section 10 @ 0x7429c)
		libstdc++.so:__gxx_personality_sj0()+0x4D4 (section 10 @ 0x74f18)
		module aOS4.1:SObjs/libgcc.so at 0x6DEDD070 (section 0 @ 0x9074)
		libstdc++.so:__cxa_throw()+0x74 (section 10 @ 0x75448)
		a.out:main()+0x154 (section 8 @ 0x644)
		native kernel module newlib.library.kmod+0x00001f4c
		native kernel module newlib.library.kmod+0x00002b98
		native kernel module newlib.library.kmod+0x00002d5c
		a.out:_start()+0x170 (section 8 @ 0x170)
		native kernel module dos.library.kmod+0x0001b524
		native kernel module kernel+0x00036290
		native kernel module kernel+0x00036310                  
However, when changing the code a little by just commenting
the DummyClass-specific exception:

Code: Select all

  try{
     cout<<"throw error"<<endl;
     throw dc;
 // }catch(DummyClass dcr){
 //    cout<<"Dummy error!"<<endl;
  }catch(...){
      cout<<"Unknown error"<<endl;
  }
everything works fine also with the shared object version and
test outputs: "Unknown error" as expected.

So, it seems, that you can't catch specific Exceptions?
The same problem appears when the Exception is defined
and thrown within another "shared object"-library on AmigaOS4.


A suggested solution given in the thread at the temporarily amigans.net site
was to always inherit a self-defined exception from "public std::exception".

In the example case above, this means, to redefine the class 'DummyClass' by :

Code: Select all

class DummyClass : public std::exception {
  public:
    DummyClass(){};	 
};
And indeed, it works, when the class is defined within the compiled binary.
However, the same GrimReaper still seems to appear, when that self-defined
exception (including the inheritance from std::exception) is defined within a shared
library object (.so) which is dynamically linked against the main program and where
such a self-defined exception is tried to be caught.

To give more concrete information:

I compiled CLucene for AOS4 as a shared library and build my own application around it.
In the CLucene.so-library an Exception is defined which I have to catch in my application
and which causes then the above mentioned GR.


Thanks,
nexus
User avatar
Hans-Joerg Frieden
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 223
Joined: Wed Dec 08, 2010 3:52 pm

Re: Bug in shared library version of newlib's libstdc++.so?

Post by Hans-Joerg Frieden »

I'll have a look at this ASAP. It could be an issue with an unsupported reloc.
NOTICE: If you want to contact me, use E-Mail. I cannot be contacted via the forum/private messages anymore
User avatar
ssolie
Beta Tester
Beta Tester
Posts: 1010
Joined: Mon Dec 20, 2010 8:51 pm
Location: Canada
Contact:

Re: Bug in shared library version of newlib's libstdc++.so?

Post by ssolie »

Hans-Joerg Frieden wrote:I'll have a look at this ASAP. It could be an issue with an unsupported reloc.
I hit this problem way back when I was trying to port C++ Boost using newlib and shared objects.

I think I still have a very simple test case around here someplace in case you need it.

It had to do with throwing exceptions if I recall correctly. It has been a while since I worked on it.
ExecSG Team Lead
User avatar
nexus
Beta Tester
Beta Tester
Posts: 347
Joined: Mon Dec 20, 2010 2:11 pm
Location: Germany

Re: Bug in shared library version of newlib's libstdc++.so?

Post by nexus »

A fully functional shared C++ Boost Library, would be very appreciated!
Of course, a fix for this exception problem, too. :-)

nexus
Trev
Posts: 5
Joined: Sat Jun 18, 2011 5:48 pm

Re: Bug in shared library version of newlib's libstdc++.so?

Post by Trev »

Any word on whether this will be resolved in the next OS update?
Trev
Posts: 5
Joined: Sat Jun 18, 2011 5:48 pm

Re: Bug in shared library version of newlib's libstdc++.so?

Post by Trev »

Fixed in Update 4?
alekc
Posts: 50
Joined: Sat Jun 18, 2011 3:06 pm

Re: Bug in shared library version of newlib's libstdc++.so?

Post by alekc »

Trev wrote:Fixed in Update 4?
Looking at my test results I can confirm that it is fixed in U4 :D . If anyone wants I can post my sample code based on original example from problem report post.
kas1e
Beta Tester
Beta Tester
Posts: 542
Joined: Sat Jun 18, 2011 7:56 am
Contact:

Re: Bug in shared library version of newlib's libstdc++.so?

Post by kas1e »

@Trev
Dunno if i do something wrong , but i just trying to use example above, and with / without -use-dynld , on update3 and on update4, i have in shell output:

throw error
Dummy error!

And no crashes.

Trying that on my peg2.
Post Reply