Fri Nov 02 10:47:21 2012: Request 80322 was acted upon.
Transaction: Correspondence added by JDHEDDEN
       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: open
 Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >


On Fri, Nov 2, 2012 at 10:31 AM, bulk 88 <bul...@hotmail.com> wrote:
> Bug has been identified. I had a suspicion from day 1 that
> might be causing something but the why is so unexplainable
> so changing the C/XS/asm code was the last thing I would
> try.  It has to do with a garbage (since the value is
> meant only as an I32/I64 in EAX/EDX) float/double being
> loaded into ST(0) x87 register. Somehow float (as string)
> "\x01\x00\x00\x00" (since 03_Jim_Shaw.t's
> window_enumerator sub is returning I32 1) has special
> meaning or is it switching FPU flags (how?) or something.
> Why only on the 8th's time? Why only on your CygPerl and
> not my Cygnus build? Does Cygwin use a "unix" calling
> convention that changes some of the volatile registers to
> non vol (looking at asm of mt CygPerl it looked like
> normal cdecl)? What is Cygwin's policy on x87 control
> register? Does Cygwin unmask FPU exceptions and catch them
> (SEH) and process them in software and resume execution? I
> don't have answers to any of the above questions.
>
> There are 2 ways of fixing this, add more logic to the 32
> bit shell code stub written in ::Callback::MakeCB to not
> touch x87 if not returning a x87 val. Or figure out what
> happened. This might turn into a bug report for Cygwin
> runtime lib. My internet at home is still down due to the
> hurricane and I am not at my other place so I can't do any
> googling or research on this until I am back at the other
> place that has broadband. Probably next week. If you want
> to research it yourself, there should be enough info above
> for you to do it. RtlCaptureContext is what I would be
> using for debugging and printf dumping all 8 bytes of
> CBRETVAL * retval in PerlCallback in Callback.xs every
> time PerlCallback is called.

I am adding the above to the bug report for tracking
purposes.

Reply via email to