how to prevent prevent .so-calling routine to crash from segfaults in .so

how to prevent prevent .so-calling routine to crash from segfaults in .so

Post by Nabeel Shahe » Thu, 10 Jul 2003 20:24:17



Hi,

Guys I am stuck with a problem and need some help.

Platform     : Linux(RedHat 7.3)
Problem Area : Dynamic Shared Object Libraries, POSIX Threads
glibc        : 2.96

Problem:
=======
The Scenario is such that I have made a module which call a .so file
in a new thread and executes it. The .so file has to be provided by
the end-user and if that .so gives any runtime-error(SEGFAULTS), the
whole process terminates i.e. all the threads executing .so files and
more importantly my .so-calling module, which I dont want to be
terminated.

so ***IS THERE ANY WAY THAT MY SO-CALLING MODULE DOES NOT TERMINATE
DUE TO SOME SEGFAULTS IN A .SO FILE WRITTEN BY THE END-USER OF MY
MODULE?***.

Any relevant comment will be appreciated.

Best Regards,

Nabeel Shaheen
Sir Syed Research Labs
nabsha[at]UNIssuet.edu.pk (remove capitals)

 
 
 

how to prevent prevent .so-calling routine to crash from segfaults in .so

Post by Rainer Temm » Thu, 10 Jul 2003 20:54:18



> Hi,

> Guys I am stuck with a problem and need some help.

> Platform     : Linux(RedHat 7.3)
> Problem Area : Dynamic Shared Object Libraries, POSIX Threads
> glibc        : 2.96

> Problem:
> =======
> The Scenario is such that I have made a module which call a .so file
> in a new thread and executes it. The .so file has to be provided by
> the end-user and if that .so gives any runtime-error(SEGFAULTS), the
> whole process terminates i.e. all the threads executing .so files and
> more importantly my .so-calling module, which I dont want to be
> terminated.

> so ***IS THERE ANY WAY THAT MY SO-CALLING MODULE DOES NOT TERMINATE
> DUE TO SOME SEGFAULTS IN A .SO FILE WRITTEN BY THE END-USER OF MY
> MODULE?***.

> Any relevant comment will be appreciated.

Hi Nabeel,

since the *.so file is provided by the end-user we cannot assume it to be
...
   ... free of errors (can we ever assume this?)
   ... protect itself against crashes
   etc.

I think the only way to handle this problem is to use
   setjmp() /longjmp() along with a signal-handler registered for all
relevant signals.

Before each call to the user-so-file you register the actual settings with
setjump().
   Whenever a signal occurs the signal-routine will be called and can
longjmp() to
   the previously stored position. At least, this way you'll be able to
write a proper Log
   and to do a proper program-cleanup. Generally I wouldn't trust this
construction to
   be stable enough so that the program can continue...the call to the
user-so-file might
   have corrupted stack/heap and anything else (including the
jumpbuf-structure stored with
   setjmp())...so that normal operation is not longer guaranteed.

Regards ... Rainer

 
 
 

how to prevent prevent .so-calling routine to crash from segfaults in .so

Post by Casper H.S. Di » Thu, 10 Jul 2003 21:07:20



>The Scenario is such that I have made a module which call a .so file
>in a new thread and executes it. The .so file has to be provided by
>the end-user and if that .so gives any runtime-error(SEGFAULTS), the
>whole process terminates i.e. all the threads executing .so files and
>more importantly my .so-calling module, which I dont want to be
>terminated.
>so ***IS THERE ANY WAY THAT MY SO-CALLING MODULE DOES NOT TERMINATE
>DUE TO SOME SEGFAULTS IN A .SO FILE WRITTEN BY THE END-USER OF MY
>MODULE?***.

No.  Well, you can prevent it from terminating your program by catching
SIGSEGV and doing a longjump or some such.

But then you're left possibly with:

        - mutex locks held by the crashed thread
        - heap corruption caused by the crashed thread
        - other corruption/inconsitencies caused.

I.e., the best you can do is die and restart.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

how to prevent prevent .so-calling routine to crash from segfaults in .so

Post by m.. » Thu, 10 Jul 2003 20:51:24



> so ***is there any way that my so-calling module does not terminate
> due to some segfaults in a .so file written by the end-user of my
> module?***.

First, don't yell (fixed).  The answer is no.  If a module contains
bad code that trashes your stack and/or head, there's nothing you can
do to recover.  Depending on your design, it could be possible to run
all modules in separate processes, communicating through sockets,
shared memory, or whatever.  Then only the misbehaving process would
be terminated.

--
M?ns Rullg?rd

 
 
 

how to prevent prevent .so-calling routine to crash from segfaults in .so

Post by Neil Horma » Thu, 10 Jul 2003 21:41:22



> Hi,

> Guys I am stuck with a problem and need some help.

> Platform     : Linux(RedHat 7.3)
> Problem Area : Dynamic Shared Object Libraries, POSIX Threads
> glibc        : 2.96

> Problem:
> =======
> The Scenario is such that I have made a module which call a .so file
> in a new thread and executes it. The .so file has to be provided by
> the end-user and if that .so gives any runtime-error(SEGFAULTS), the
> whole process terminates i.e. all the threads executing .so files and
> more importantly my .so-calling module, which I dont want to be
> terminated.

> so ***IS THERE ANY WAY THAT MY SO-CALLING MODULE DOES NOT TERMINATE
> DUE TO SOME SEGFAULTS IN A .SO FILE WRITTEN BY THE END-USER OF MY
> MODULE?***.

> Any relevant comment will be appreciated.

> Best Regards,

> Nabeel Shaheen
> Sir Syed Research Labs
> nabsha[at]UNIssuet.edu.pk (remove capitals)

How about instead of creating a new thread, you re-architect your
program to fork a child process to interact with the user supplied
shared library?  That way, if the .so file causes a segfault, the child
will terminate, but the parent can detect the unclean exit, and inform
the user, without needing to shut the whole program down.
HTH
Neil
 
 
 

how to prevent prevent .so-calling routine to crash from segfaults in .so

Post by Nabeel Shahe » Fri, 11 Jul 2003 05:23:23




> > Hi,

> > Guys I am stuck with a problem and need some help.

> > Platform     : Linux(RedHat 7.3)
> > Problem Area : Dynamic Shared Object Libraries, POSIX Threads
> > glibc        : 2.96

> > Problem:
> > =======
> > The Scenario is such that I have made a module which call a .so file
> > in a new thread and executes it. The .so file has to be provided by
> > the end-user and if that .so gives any runtime-error(SEGFAULTS), the
> > whole process terminates i.e. all the threads executing .so files and
> > more importantly my .so-calling module, which I dont want to be
> > terminated.

> > so ***IS THERE ANY WAY THAT MY SO-CALLING MODULE DOES NOT TERMINATE
> > DUE TO SOME SEGFAULTS IN A .SO FILE WRITTEN BY THE END-USER OF MY
> > MODULE?***.

> > Any relevant comment will be appreciated.

> > Best Regards,

> > Nabeel Shaheen
> > Sir Syed Research Labs
> > nabsha[at]UNIssuet.edu.pk (remove capitals)

> How about instead of creating a new thread, you re-architect your
> program to fork a child process to interact with the user supplied
> shared library?  That way, if the .so file causes a segfault, the child
> will terminate, but the parent can detect the unclean exit, and inform
> the user, without needing to shut the whole program down.
> HTH
> Neil

Hi Guys,

Thanx a lot for ur valueable suggestion/information.

I think Neil is right and therefore am restructuring the application
as this seems to be the only legal way out of this hazardous
environment.

Thanx again for your comments

Best Regards,

Nabeel Shaheen
Sir Syed Research Labs
nabsha[at]UNIssuet.edu.pk (remove capitals)

 
 
 

1. Load-balancing web server software prevents site crashes!

PolyServe Corporation announces version 1.3 of Understudy, its flagship
software application. Understudy enables a Webmaster or Network
Professional to set up a high availability web server cluster with IP
service monitoring, failure detection, load balancing and automatic
failover.

Understudy has broad OS support, including Windows NT, Sun Solaris, Linux
and Free BSD. No specialized hardware is required and it will work with
any webserver. By using Understudy on two or more servers users can be
assured their websites will always be available and will not be brought
down by server hardware or software failures.

Understudy is available at a breakthrough price point starting as low as
$499. per server pair. We are offering a 30-day free trial - please click
here http://www.polyserve.com/form.html to download your free evaluation
copy, or to find out more about Understudy.

For more information please visit our web site http://www.polyserve.com

PolyServe, Inc.
Gary Hemminger, Director, Product Management

918 Parker Street, Suite A12
Berkeley, CA 94710
Phone: 510.665.2929/fax: 510.649.0660

2. USENIX Winter 1993 Technical Conference - Tutorial Program

3. Compiling a program crashed X and prevented me from soft-booting

4. proc fs in daemons

5. Prevent Kernel Panic after Telnet Crash ?

6. failedlogins file format/root password

7. How to prevent removing terminal from serial port from crashing server

8. IPTables vs. DNS (or : iptables doesn't change sourceport when MASQ'ing)

9. preventing those crashes: is the kernel the culprit?

10. Maybe OT: This USB device prevents my computer from posting

11. prevent users from printing binaries

12. How to prevent Answerbook from accessing the network?

13. Preventing login on /dev/console