Thu Jan 21 20:17:53 2016: Request 80322 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: 'make test' failure - 03_Jim_Shaw.t - invalid unpack type
Broken in: 0.72, 0.73
Severity: Important
Owner: Nobody
Requestors: jdhed...@cpan.org
Status: resolved
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
On Thu Jan 21 17:02:33 2016, TONYC wrote:
> That sounds like a bug we had in one of the perl BBC reports last
> year.
>
> A module was calling the Time::HiRes Time::NVtime entry point from C
> with the wrong prototype, mis-balancing the FPU stack, which resulted
> in a NaN in a unrelated location.
That is what was happening to me here. NAN in unrelated location.
> I ended up diagnosing it by adding code to the perl run loop to check
> the FPU stack was empty, and abort with the current location in the
> perl code when it wasn't.
You aren't the first to modify the run loop like that. DebugBreak() is my fav
function. Some bugs aren't reproducible if you run the .t manually outside of
"make test", or its a one liner that ran a one liner that crashed, not the root
parent .t, or if you switch TAP::Harness to verbose mode since the bug is
memory corruption. DebugBreak() takes care of all those permutations.
My failure to diagnose it originally 3 years ago was
A. I couldn't reproduce it
B. I thought elements just fall off the end of the FPU stack, not that the FPU
stops working until there is space on the FPU stack
C. calling convention docs said the FP stack/FP registers are volatile, only
FPU Control Word is non-vol (if you change rounding mode, you must restore it
was whatever the caller had it as). I guess that is kindda false as the stack
apparently must be empty according to this 2014 book
https://books.google.com/books?id=plInCgAAQBAJ&lpg=PA90&dq=&pg=PA110#v=onepage&q&f=false
but the 2014 book doesn't outright say that that is an API contract that the
FPU stack must be empty
The 2 byte fix at
https://github.com/bulk88/perl5-win32-api/commit/ad3696fc998539ca9c56adc8664f3b21ae0ac0c3#diff-f00ae59afe5413c3b9c279cd5ae6104bR307
just means just ST(0) is set now, all the other FPU registers (ST(1) through
ST(7)) are now assumed to be non-vol and are left the way they were found
(probably empty) upon entry to the shellcode callback.
