*{"$callpkg\::$_"} = \&{"$pkg\::$_"} foreach @_;
[download]

... When I tried to feed the debugger with this:

&{"$pkg\::$_"}
[download]

\&... would never do what &... does. \&... takes a reference to a subroutine while &... invokes a subroutine. So what &{"$pkg\::$_"} does is rather irrelevant. It is indeed unfortunate that Params::Classify::is_string() stupidly produces an endless recursive loop when not given any parameters. But that likely has nothing to do with your original problem.

The author of that module even included:

sub is_string($);
[download]

Which makes it fatal to call is_string() with no arguments... unless you use the prefix & to disable sub prototype checking, as you did. So even a bug report against the module might not yield anything.

It is crashing in the module Exporter, line 64:

How does it crash?

How does it crash?

Sorry, I should have been more specific.

The program crashes with SEGFAULT after executing this line (Exporter.pm, line 64):

64:       *{"$callpkg\::$_"} = \&{"$pkg\::$_"} foreach @_;
[download]

\&... would never do what &... does. \&... takes a reference to a subroutine while &... invokes a subroutine. So what &{"$pkg\::$_"} does is rather irrelevant. It is indeed unfortunate that Params::Classify::is_string() stupidly produces an endless recursive loop when not given any parameters. But that likely has nothing to do with your original problem.

Indeed, you are right. However the expression \&{"$pkg\::$_"} entered into the perl debugger yields the same result - SEGFAULT crash.

I've been trying to find the part of the line 64 that causes problems - and it shows that the bad part is the expression \&{"$pkg\::$_"}. Perl somehow cannot correctly resolve the function Params::Classify::is_string.

My previous post followed with a GDB backtrace generated from the core dump of the crashed program. It shows where exactly the segfaulted.

Btw. have you tried that program? Does it work on your computer?

I'm not surprised that Params::Classify fails when used more than once in the same process.

Here it declares a single data structure per process:

static struct rtype_metadata {
    char const *desc_noun, *keyword_pv;
    SV *keyword_sv;
} rtype_metadata[RTYPE_COUNT] = {
    { "scalar", "SCALAR", NULL },
    { "array",  "ARRAY",  NULL },
    { "hash",   "HASH",   NULL },
    { "code",   "CODE",   NULL },
    { "format", "FORMAT", NULL },
    { "io",     "IO",     NULL },
};
[download]

That data structure will eventually contain pointers to Perl variables, as set here:

    rtypemeta->keyword_sv =
        newSVpvn_share(rtypemeta->keyword_pv,
            strlen(rtypemeta->keyword_pv), 0);
[download]

I don't believe that you can safely use Perl variables from one interpreter instance in a different instance of the interpreter.

You could try loading Params::Classify in multiple Perl "threads" (using threads.pm) and see if that also dies and file a bug against the module.

Or you could just get similar functionality in a way that doesn't require such a large chunk of XS code (since XS code is, by far, the single biggest source of core dumps in Perl -- because it is extremely hard to write robust XS code), especially XS code that entwines itself into everything by hooking 'entersub' and doing manipulations of the Perl opcodes.

When searching the module documentation for some hint of why it hooked 'entersub' and manipulated opcodes, I found none, but I did find:

This module is implemented in XS, with a pure Perl backup version for systems that can't handle XS.

So, if you really want Params::Classify features, you could use the non-XS implementation (you'll have to figure out how that is done).

Btw. have you tried that program?

No. I have no intention of even downloading Param::Classify, much less trying to reproduce your problem locally.

- tye