[perl #20928] sigsegv when destroying embedded interpreter
A . Bergman
On torsdag, feb 13, 2003, at 19:47 Europe/Stockholm, Bryan Hunt (via
RT) wrote:
> I've attached a testcase that will trivially reproduce a sigsegv inside
> the interpreter. The problem occurs when an embedded interpreter is
> destroyed from within an xsub. The included readme explains how to
> reproduce the problem. Note that this is a fairly serious problem for
> me.
>
>
>
>
> Regards,
>
> Bryan Hunt
> GMD Simulation & Verification, IBM, Austin TX (512) 838-6273 or T/L
> 678-6273
> A good engineer makes the possible a reality; a great engineer makes
> the
>
Hi,
I will take a look at this, we are doing this from threads.xs so it
should be possible.
Arthur
A . Bergman
On torsdag, feb 13, 2003, at 19:47 Europe/Stockholm, Bryan Hunt (via
RT) wrote:
>
> I've attached a testcase that will trivially reproduce a sigsegv inside
> the interpreter. The problem occurs when an embedded interpreter is
> destroyed from within an xsub. The included readme explains how to
> reproduce the problem. Note that this is a fairly serious problem for
> me.
>
>
>
>
> Regards,
>
> Bryan Hunt
> GMD Simulation & Verification, IBM, Austin TX (512) 838-6273 or T/L
> 678-6273
>
Oh, it is not very surprising that you are getting a segfault, since
you are destroying the interpreter that is running the XSUB, so that
when you return from the XSUB there is nothing left!
The only solution would be for you to longjmp out of the XSUB to some
place that does not depend on the interpreter.
Arthur
A . Bergman
On torsdag, feb 13, 2003, at 22:53 Europe/Stockholm, Bryan Hunt wrote:
> [perl #20928] sigsegv when destroying embedded interpreter
>
> This problem also occurs when I destroy the perl interpreter from
> another
> thread, but I didn't want to complicate the example with threading
> code.
>
>
> Regards,
>
> Bryan Hunt
> GMD Simulation & Verification, IBM, Austin TX (512) 838-6273 or T/L
> 678-6273
> A good engineer makes the possible a reality; a great engineer makes
> the
> impossible possible.
>
>
If you are destroying the perl interpreter from another thread, and
that perl interpreter is being used, there is no great surprise that
you are getting segfaults, and there is nothing we can do to stop it.
As I said earlier, the only way to destroy the perl interpreter that
invoked a xsub inside the xsub, is to longjmp out of there afterwards.
Arthur
Dave Mitchell
> Well, then I need a suggestion for a workaround. Here is a little more on
> the situation:
>
> I basically have two threads, one that runs the main c++ code, and one
> that runs an embedded interpreter. I've restricted the threads such that
> only the c++ code or the interpreter may run at a given time - they are
> not allowed to run simultaneously. The perl script is allowed to call
> xsubs that cause the c++ code to do some processing.
You don't make it clear whether this xsub/c++ code is excuted by the Perl
thread or the main thread; if the latter, how is control passed back and
forth between the two threads?
> It is possible for
> the c++ code to detect a condition in which if the perl script were
> allowed to continue, a core dump would occur so I must shut down the
> interpreter from the c++ code while an xsub is waiting to return from the
> suspended thread. I'm wondering if I could just kill the entire thread
> without calling perl_delete() and perl_free()? Any other suggestions?
--
You live and learn (although usually you just live).
Dave Mitchell
> When perl calls the xsub, some state information is set up, then the xsub
> will suspend itself and wake up the main thread. The main thread will do
> some processing with the state information, and then eventually suspend
> itself and wake up the perl thread where the xsub then returns back to the
> perl interpreter.
>
> I think I have a solution, though it's not ideal. I have a way of
> detecting that the perl thread is still running from the main thread and I
> can kill the perl thread from the main thread. If I detect that the perl
> thread has completed, I can destroy the interpreter gracefully. This
> seems to be working, but I'm a little concerned about leaking memory by
> using this method.
>
> It might be nice if a call like perl_stop() could be added that would set
> a flag in the interpreter, and then when the interpreter returns from an
> xsub, it could check that flag before continuing and terminate the script
> if the flag is set. This would allow me to return from the xsub, not
> execute any more perl, and gracefully shut down the interpreter.
If you have a bit of XS code that has decided it wants to kill off the
perl interpreter, then why not just call croak()?
Then you can trap this at the outermost level, and destroy the
interpreter - depending on what your doing, a call to eval_sv()
or eval_pv() might do the trick.
Dave.
--
To collect all the latest movies, simply place an unprotected ftp server
on the Internet, and wait for the disk to fill....
A . Bergman
On fredag, feb 14, 2003, at 16:28 Europe/Stockholm, Bryan Hunt wrote:
>
> Well, then I need a suggestion for a workaround. Here is a little
> more on
> the situation:
>
> I basically have two threads, one that runs the main c++ code, and one
> that runs an embedded interpreter. I've restricted the threads such
> that
> only the c++ code or the interpreter may run at a given time - they are
> not allowed to run simultaneously. The perl script is allowed to call
> xsubs that cause the c++ code to do some processing. It is possible
> for
> the c++ code to detect a condition in which if the perl script were
> allowed to continue, a core dump would occur so I must shut down the
> interpreter from the c++ code while an xsub is waiting to return from
> the
> suspended thread. I'm wondering if I could just kill the entire thread
> without calling perl_delete() and perl_free()? Any other suggestions?
>
>
Hi,
One possible solution is have the main thread call perl_destruct and
perl_free and then pthread_cancel the thread so it won't execute any
more of the perl interpreter.
Arthur
A . Bergman
On måndag, feb 17, 2003, at 16:47 Europe/Stockholm, Bryan Hunt wrote:
>
> This proposal does not work. calling perl_destruct from the main
> thread
> is what causes a SIGSEGV. Here is the stack trace:
>
> perl_destruct()
> Perl_op_free()
> Perl_op_free()
> Perl_op_clear()
>
>
But you cannot call perl_destruct while perl is running, you need to
longjump out of the xsub and then call perl_destruct.
Arthur