Re: shared scalar freed early

In addition to BrowserUks diagnosis, my random guess would be that you have a not-so-threadsafe XS component involved, which thrashes some part of memory. Perl recognizes when memory is allocated in one thread and then freed in another thread and does not like that, hence your error message. Maybe, this is caused by some XS component used from more than one thread.

One approach to test this hypothesis would be to rewrite your script so that no modules are used which have an XS component, and to replace all essential parts with pure Perl components. Ideally, this makes the problem go away.

Comment on Re: shared scalar freed early

Replies are listed 'Best First'.
Re^2: shared scalar freed early by chris212 (Scribe) on Feb 22, 2017 at 19:57 UTC
Actually, I forgot about the 3rd party SWIG module that is require'ed in the main thread (conditionally, Win32::API for Windows). The worker threads inherit and use it. That could very well be the culprit, although I'm not sure why it would change the refcount on my shared scalar. I could try taking out the module and see if I can replicate the problem. It should run much faster without it.	[reply]
Re^3: shared scalar freed early by chris212 (Scribe) on Feb 22, 2017 at 22:20 UTC
Nope. I got it to crash after removing the module, so I don't think that module is the problem.	[reply]
Re^2: shared scalar freed early by chris212 (Scribe) on Feb 22, 2017 at 18:00 UTC
There are no XS components being utilized when it crashed. The only non-core component that can be used is Text::CSV_XS, but it will crash even if the "require Text::CSV_XS" line is never executed.	[reply]
Re^3: shared scalar freed early by syphilis (Archbishop) on Feb 24, 2017 at 01:02 UTC
There are no XS components being utilized when it crashed. The only non-core component that can be used is ... There are many core modules that have an XS component. Cheers, Rob	[reply]