Programming This 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.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
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.
|
 |
12-08-2005, 10:16 PM
|
#1
|
Member
Registered: Mar 2005
Posts: 61
Rep:
|
dlopen(), causing SIGBUS signal.... help
Hi all,
I m trying to open a corrupted .so file, through
dlopen() function. Some time it is returning error safely. And some time it is causing SIGBUS signal to be delivered. Because of this signal my program is crashing.
Corrupted .so file, means not complete shared library file i.e. half or 3/4 of a shared library file.
---------Help...
Can any body help me, why this is causing SIGBUS?
And how to avoid this program crash?
Is it safe to ignore SIGBUS signal?
Is there any such command or system call which can verify whether a given shared library is corrupted or not?
--------- Thanking U all
[ Note :: I m using C on Suse Linux platform ]
With Regard
RajSun
|
|
|
12-08-2005, 11:00 PM
|
#2
|
Member
Registered: May 2004
Posts: 552
Rep:
|
This signal can not be caught or ignored, so you don't have a choice - it will terminate your application if you like it or not.
Now the library file, if its bad you again have no choice. Either get a good copy of the file or stop using it because it will never work.
|
|
|
12-08-2005, 11:48 PM
|
#3
|
Member
Registered: Mar 2005
Posts: 61
Original Poster
Rep:
|
Thanks for your reply...
Thanks for reply... man.
I want to know that whether is there any way to make sure the given shared library file is corrupted ?
With Regard
RajSun
|
|
|
12-09-2005, 07:32 PM
|
#4
|
Member
Registered: May 2004
Posts: 552
Rep:
|
Yes, compare the questionable file with the good one.
$ cmp unknown.so goodone.so
unknown.so goodone.so differ: byte 1, line 1
so you know its bad because they differ.
Like I said you have to get a good copy of the file first.
Compile it from source if you have to.
Edit:
Try running nm on the file, it should print out some error
message if corrupt.
Last edited by randyding; 12-09-2005 at 07:38 PM.
|
|
|
12-09-2005, 10:52 PM
|
#5
|
Member
Registered: Jun 2005
Posts: 542
Rep:
|
Quote:
Originally Posted by randyding
This signal can not be caught or ignored, so you don't have a choice - it will terminate your application if you like it or not.
|
This is not true. Quoting signal(7):
"The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored."
What's the use of the pointers to the functions contained in the shared library? Remember that shared libraries are loaded dinamically. Post some code if you can.
|
|
|
12-09-2005, 11:32 PM
|
#6
|
Member
Registered: May 2004
Posts: 552
Rep:
|
My experience with Bus faults is with embedded (not intel), when you get one of these you're so screwed there's often no good stack or program counter to continue execution. If intel allows you to catch one of these (it very well could) it won't help the OP because his problem is the library file's size was cut off through some copy error. His words "i.e. half or 3/4 of a shared library file". This is not recoverable whether the os actually lets you catch the signal or not. The process is doomed.
|
|
|
12-10-2005, 12:09 AM
|
#7
|
Member
Registered: Jun 2005
Posts: 542
Rep:
|
It may be that with 3/4 the size you're hitting an incomplete instruction or a reference to data or functions that aren't present. By the way, if you're trying to make your program robust, then catching SIGBUS may help if you're trying to use a shared library as a plugin. You'd have to know where in the program you're dealing with functions in this library, like installing the handler before and so on
|
|
|
12-11-2005, 10:07 PM
|
#8
|
Member
Registered: Mar 2005
Posts: 61
Original Poster
Rep:
|
[HTML]Edit:
Try running nm on the file, it should print out some error
message if corrupt.[/HTML]
Thanks.... randyding
For me nm worked perfectly. This command is verifying the given .so file. If it is incomplete then it's return ing non zero value "256" and saying the symboles are missing.
Once again thanking u .....
With Regard
RajSun.
|
|
|
12-11-2005, 10:08 PM
|
#9
|
Member
Registered: Mar 2005
Posts: 61
Original Poster
Rep:
|
Quote:
Edit:
Try running nm on the file, it should print out some error
message if corrupt.
|
Thanks.... randyding
For me nm worked perfectly. This command is verifying the given .so file. If it is incomplete then it's returning non zero value "256" and saying the symbols are missing.
Once again thanking u .....
With Regard
RajSun.
Last edited by rajsun; 12-11-2005 at 10:11 PM.
|
|
|
All times are GMT -5. The time now is 08:35 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|