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

Have a question about our Software Developer Kit? Ask them here.

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

Postby nexus » Thu Apr 14, 2011 11:57 am

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
nexus
Beta Tester
Beta Tester
 
Posts: 347
Joined: Mon Dec 20, 2010 3:11 pm
Location: Germany

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

Postby Hans-Joerg Frieden » Thu Apr 14, 2011 2:57 pm

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
Hans-Joerg Frieden
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 223
Joined: Wed Dec 08, 2010 4:52 pm

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

Postby ssolie » Thu May 19, 2011 5:20 am

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
ssolie
Beta Tester
Beta Tester
 
Posts: 1010
Joined: Mon Dec 20, 2010 9:51 pm
Location: Canada

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

Postby nexus » Thu May 19, 2011 2:48 pm

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

nexus
User avatar
nexus
Beta Tester
Beta Tester
 
Posts: 347
Joined: Mon Dec 20, 2010 3:11 pm
Location: Germany

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

Postby Trev » Sat Jun 18, 2011 10:43 pm

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

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

Postby Trev » Sat Dec 24, 2011 6:31 pm

Fixed in Update 4?
Trev
 
Posts: 5
Joined: Sat Jun 18, 2011 6:48 pm

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

Postby alekc » Tue Dec 27, 2011 11:19 pm

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.
alekc
 
Posts: 50
Joined: Sat Jun 18, 2011 4:06 pm

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

Postby kas1e » Wed Dec 28, 2011 10:51 am

@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.
kas1e
Beta Tester
Beta Tester
 
Posts: 481
Joined: Sat Jun 18, 2011 8:56 am


Return to SDK Support

Who is online

Users browsing this forum: No registered users and 2 guests