[SOLVED] Crashes in throwing exceptions if code compiled in 32 bit explicity on 64 bit system
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Crashes in throwing exceptions if code compiled in 32 bit explicity on 64 bit system
Hi LQ Memebers,
We have one shared libary which is used by Java Program using JNI. In this native libary, we throw standard exception using JNI methods,which by the way work fine.
Due to some constraint, we are forced to compile this library in both modes ( 32 & 64 bit) only on 64 bit server using -m32 options.
Now, the 32 bit compiled version is run on 32 bit systems and the libary crashes while attempting to throw an exception to Java program. However, if the libary is compiled on 32 bit system, it works just fine.
This is my error class,
#include <exception>
#include <sstream>
//! Base error class
class Error : public std::exception {
public:
/*! The explicit use of this constructor is not advised. Use the GO_FAIL macro instead */
Error(const std::string& message = "") : message_(message) {};
/*! the automatically generated destructor would not have the throw specifier */
virtual ~Error() throw() {}
Presumably, when a ball is thrown, there's someone else to catch it. It's the same concept when dealing with exceptions... if one is thrown, then somewhere in the code, it should be caught.
Try augmenting your code to have the following construct:
Presumably, when a ball is thrown, there's someone else to catch it. It's the same concept when dealing with exceptions... if one is thrown, then somewhere in the code, it should be caught.
Try augmenting your code to have the following construct:
yes sire, this is very obvious code fragments which i had not put in my post. It does not even come to catch() block. It just fails during throw Error("Any error"). However, it works fine if the shared library had been compiled on 32 bit server. This is an issue regarding Cross compilation. It has something to do with this Error class.
... It does not even come to catch() block. It just fails during throw Error("Any error"). However, it works fine if the shared library had been compiled on 32 bit server. This is an issue regarding Cross compilation. It has something to do with this Error class.
Through some experimentation, I was able to get the following code to work, under separate environments (32-bit and 64-bit), however I was unable to use the -m32 option on my 64-bit system; presumably this system is missing some critical development files.
Through some experimentation, I was able to get the following code to work, under separate environments (32-bit and 64-bit), however I was unable to use the -m32 option on my 64-bit system; presumably this system is missing some critical development files.
This is quite kind of you to do this experimentation. I really appreciate that. However, i am facing this problem because the shared library is compiled with -m32 option on 64 bit systems. You need to install glibc-devel.i686 (any version) package on your system. I too faced this issue in the begining. After this, probably you can try and run this program to replicate the issue. I will also try and do that.
This is quite kind of you to do this experimentation. I really appreciate that. However, i am facing this problem because the shared library is compiled with -m32 option on 64 bit systems. You need to install glibc-devel.i686 (any version) package on your system. I too faced this issue in the begining. After this, probably you can try and run this program to replicate the issue. I will also try and do that.
Hi all,
I have been able to resolve this issue. I had some .c source files where gcc is used instead of g++ for compilation. Now, It seems that i missed to have -m32 option in the configuration of make files used for .c files and i had hided warning messages with -w option in all the makefiles. As a result, i could not see what was going on during the compilation.
I have corrected these mistakes and now i can see it working fine.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.