Since the exception appears to be being thrown within Math::Prime::Util::GMP, this becomes my prime suspect.   Looking at line 132 on "metacpan.org," I see that it is call to _GMP_destroy() and that it occurs within an END block.   This source-code in turn can be found at https://github.com/danaj/Math-Prime-Util-GMP/blob/master/gmp_main.c.

My hypothesis now becomes that GMP, itself, is not thread/process safe.   That the actual root cause of your problem does not lie in your Perl code, but in the C-language implementation of GMP.   Of course this might be caused by some interaction with Perl’s implementation of threading, and/or with precisely what happens in an END-block, but the next experiment that I would perform is to cobble-up a C-language program that launches a number of C-language child processes to see if you can replicate the problem outside of the Perl environment.   I did not see any open or closed issues either on MetaCpan or GitHub that specifically talked about threading/process issues, but I don’t know how often the users of this package routinely attempt to use it that way.

Exploring the source-code for the term “memory,” I stumbled upon a reference in expr.c to an external, mp_get_memory_functions(), which is probably one step closer to the actual way that GMP does memory management.   If there is anything buried in the bowels of this thing which needs a mutex in a multi-process environment, this would be more than sufficient to cause a problem like this and to make it thoroughly unpredictable.   Perl would now be exonerated – and, I suspect, it is.