Bug in shared library version of newlib's libstdc++.so?
Posted: Thu Apr 14, 2011 10: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:
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:
However, when changing the code a little by just commenting
the DummyClass-specific exception:
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 :
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
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;
}
"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
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;
}
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(){};
};
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
. If anyone wants I can post my sample code based on original example from problem report post.