🚀 go-pugleaf

sonicshaheen@yahoo.com (Nabeel Shaheen) writes:

> 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
mru@users.sf.net

"Nabeel Shaheen" <sonicshaheen@yahoo.com> wrote:
> 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

sonicshaheen@yahoo.com (Nabeel Shaheen) writes:

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

Nabeel Shaheen wrote:
> 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

Neil Horman <nhorman@lvl7.com> wrote in message news:<4UTOa.1513$zJ6.1404@fe02.atl2.webusenet.com>...
> Nabeel Shaheen wrote:
> > 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)