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

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.

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

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.

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.

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.

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

[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.

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.