So you'd like to help? Cool.

Bug tracking is via CPAN RT at
https://rt.cpan.org/Dist/Display.html?Name=Devel-Size

If you want to send a patch, attaching it to an RT ticket is useful. Don't worry
if it's not perfect - it's much easier to review an adapt a patch that than to
start from scratch. But patching this module is often hard - there are easier
ways to help:

Bug reports also useful. Please include the full `perl -V` output to give not
just version and platform, but also the specific build options.

The module is purposely relying on implementation details that may change
underneath it, and hence is often sensitive to obscure details of the build
choices. It has to make a lot of (naughty) assumptions about the core internals,
so regressions happen when the core changes and the module doesn't keep up.
This is the most frequent cause of failing tests. In this case, it's helpful to
know what particular commit in the core caused it to break. If you have a
suitably powerful machine, can run this automatically.

If you don't have a copy yet:

   git clone https://perl5.git.perl.org/perl.git

(currently about 160M of download)

then from the inside the checkout run a bisect. For example, if on your system
the regression tests for Devel::Size are now failing on the current development
version of perl but the pass with an earlier stable release version, you can run this to
automatically find which commit broke the tests:

    ./Porting/bisect.pl --module=Devel::Size

See `./Porting/bisect.pl --help` for all the options; --with-module=Devel::Size
might also be useful if you have a specific test case.

Beware - even on a modern machine this might take a couple of hours. If you
have a laptop plug it in, and best to let it run overnight or when the machine
would otherwise be idle.

If you aren't able to do this, don't worry, but if you are, awesome - sometimes
from this it's immediately obvious what the likely cause is, which is a great
morale boost for starting to figure out a fix.

If you *are* able to do this, and want to actively help, go look to see if there
are other open tickets without any indication of which core commit might have
broken it, and see if you can replicate the problem locally, and if so run a
bisect to try to find the cause.

Two tools that can be very useful for diagnosing problems

1) valgrind - a tool you can usually install using your OS package manager
2) Address Sanitizer (ASAN) - options for the C compilers gcc and clang

valgrind can be used to run your existing built perl binary and Devel::Size and
report on illegal memory accesses that would otherwise would silently return
garbage data. It's great for a quick test of an existing problematic test case,
but slows execution down massively, and is not (yet) that useful for automatic
bisecting.

ASAN requires you to (re)build perl from source with it, which in turn requires
invoking perl's ./Configure with non-default options, so it's a bit more
involved. However, the slowdown is not as severe as valgrind, and it is possible
to use it for automated bisecting.