in reply to Partial troubleshooting of Win32::Process::Memory and request for fixes

It stops at the call to get_memlist and that is just a wrapper for _GetMemoryList.

Perl process continues to run loading one core. Looks like endless loop starting at this line. I changed 4 instances of unsigned to ULONGLONG, then

perl Makefile.PL gmake

and

perl -Mblib=blib -MWin32::Process::Memory -E "say Win32::Process::Memo +ry->new({ pid=>6496 })->get_memtotal" 127885312

(6496 being Notepad's PID). Is it reasonable number? And solution? If so, it was just intuition (inspired by this), I'm not any good at XS to write good formal universal solution.

Replies are listed 'Best First'.
Re^2: Partial troubleshooting of Win32::Process::Memory and request for fixes
by syphilis (Archbishop) on Jul 05, 2018 at 00:13 UTC
    I changed 4 instances of unsigned to ULONGLONG

    Well spotted vr - but I'm guessing that change will pose problems on perls whose IV/UV is not "long long".

    I think (untested) it would be better to replace the 4 occurrences of "unsigned" with "UV" as that should be portable across all builds of Windows perl.

    Update: Bad guess. Either ULONGLONG or UV is fine with vr's one-liner if ptrsize and ivsize are both 8. Else the one-liner hangs irrespective.
    Portability will require a little more investigation.

    Cheers,
    Rob