The simplest command line piping in a threaded build of bleadperl on
VMS now gives the following errors:
$ perl -e "print 'ok';" | exit
panic: free from wrong pool.
panic: free from wrong pool during global destruction.
%C-F-EBADF, bad file number
I'm not sure where the bad file number comes from, but what's
happening with the pool messages is that Perl_safesysfree in util.c
has some new code that checks to see if we are deallocating memory
from the same thread in which we allocated it (or, more properly,
from within the same Perl interpreter context), and it yelps if not.
VMS, command-line piping is implemented by Perl itself, and such a
pipe is opened at startup time before any thread context has been
initialized. We are using Newx() to allocate memory for the
structures used by our homegrown pipe implementation and Safefree()
to deallocate them, but this gets us in trouble because for a
command-line pipe we allocate before there is any thread context
(my_perl == NULL) and deallocate after. Even if there is only ever
one interpreter in the process, it looks like we are allocating and
deallocating from different interpreters.
There are some pipe structures that are clearly intended to be
process-wide, shared by all pipes regardless of what thread they're
in. I see no harm in simply using malloc() and free() for these and
side-stepping the interpreter context issue.
But there are other structures that are pipe-specific, and it seems
like a good idea to keep the new sanity check that ensures we close a
pipe and deallocate its structures from within the same interpreter
context where it was opened. But I haven't thought of a good way to
do that for the case where the pipe is opened when there is no
context at all yet. Any suggestions?