Re: reinitializing embedded perl interpreter: undefined subrouting called during global destruction

But after reinitializing, the first time I call a Clock method,

Sounds like you are hanging onto some pointers within your application that were produced by the first instantiation of the interpreter, and when you restart the interpreter those pointers are no longer valid.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re: reinitializing embedded perl interpreter: undefined subrouting called during global destruction

Replies are listed 'Best First'.
Re^2: reinitializing embedded perl interpreter: undefined subrouting called during global destruction by kingkongrevenge (Scribe) on Mar 31, 2009 at 01:29 UTC
The XS code has `extern InternalClass` pointers in it that are referenced in XS function bodies: `extern SomeClass sc; int blah() CODE: RETVAL = sc->blah(); OUTPUT: RETVAL` [download] Would perl zero out my `sc` pointer? I'm sure I don't reset it. Other than that I don't have any relevant pointers declared myself.	[reply] [d/l] [select]
Re^3: reinitializing embedded perl interpreter: undefined subrouting called during global destruction by BrowserUk (Patriarch) on Mar 31, 2009 at 02:28 UTC
Hm. Impossible to say given the sparsity of the information. Two thoughts come to mind which may or may not be relevant on your (unstated) platform: On windows, DLLs (which is where your XS code lives) tend to get loaded once per application. So, if you have any static data (pointers) that get initialised when the module is loaded, with values that derive from the interpreter, they may not get re-initialised when a new interpreter is loaded. I've no idea if this is the case with .so's on other platforms. You mentioned that you get problems when calling methods, but you don't mention (re-)creating the instances on which you are calling those methods. If your application code stores any pointers--for example, callback addresses--from the first interpreter and tried to reuse them once you've spawned the second instance, those retained pointers are quite likely to be broken. Given the generality of the problem description, the best anyone can offer is generalised possibilities for you to look for. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]