Sun Nov 11 17:13:54 2012: Request 80322 was acted upon.
Transaction: Correspondence added by JDHEDDEN
       Queue: Win32-API
     Subject: Re: [rt.cpan.org #80322] '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 >


It is possible this has anything to do with the compiler flags I use:

-march=pentium4 -mfpmath=sse -mieee-fp -mmmx -msse -msse2


On Sat, Nov 10, 2012 at 10:31 PM, Daniel Dragan via RT <
bug-win32-...@rt.cpan.org> wrote:

> <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
>
> Attaching private mail for the record.
>
> ________________________________
> > From: jdhed...@cpan.org
> > Date: Tue, 6 Nov 2012 12:50:49 -0500
> > Subject: Re: [rt.cpan.org #80322] 'make test' failure - 03_Jim_Shaw.t -
> > invalid unpack type
> > To: bul...@hotmail.com
> > CC: rur...@x-ray.at
> >
> > Output Attached
> >
> >
> > On Sat, Nov 3, 2012 at 1:38 AM, bulk 88
> > <bul...@hotmail.com<mailto:bul...@hotmail.com>> wrote:
> >
> >
> >
> > ----------------------------------------
> > > From: jdhed...@cpan.org<mailto:jdhed...@cpan.org>
> > > Date: Fri, 2 Nov 2012 10:44:05 -0400
> > > Subject: Re: [rt.cpan.org<http://rt.cpan.org> #80322] 'make test'
> > failure - 03_Jim_Shaw.t - invalid unpack type
> > > To: bul...@hotmail.com<mailto:bul...@hotmail.com>
> > > CC: rur...@x-ray.at<mailto:rur...@x-ray.at>
> > >
> > > I leave the debugging part to you, and possibly Reini and/or the
> > > Cygwin team, as all this is Greek to me. I just had the (mis)fortune
> > > of being the first to discover the issue. You may, of course, still
> > > call upon me to perform testing and send back results if needed. Good
> > > Luck.
> >
> > Can you run this script and send back the output with CPAN Win32::API
> > .73 or any .73 github derivative I've made so far?
> >
>
> Reini
>
> On Sat, Nov 3, 2012 at 12:38 AM, bulk 88 <bul...@hotmail.com> wrote:
> > ----------------------------------------
> >> From: jdhed...@cpan.org
> >> Date: Fri, 2 Nov 2012 10:44:05 -0400
> >> Subject: Re: [rt.cpan.org #80322] 'make test' failure - 03_Jim_Shaw.t
> - invalid unpack type
> >> To: bul...@hotmail.com
> >> CC: rur...@x-ray.at
> >>
> >> I leave the debugging part to you, and possibly Reini and/or the
> >> Cygwin team, as all this is Greek to me. I just had the (mis)fortune
> >> of being the first to discover the issue. You may, of course, still
> >> call upon me to perform testing and send back results if needed. Good
> >> Luck.
> >
> > Can you run this script and send back the output with CPAN Win32::API
> .73 or any .73 github derivative I've made so far?
>
> Sure, but I cannot reproduce the bugs.
> Only t/undef.t test 2 is failing on my cygwin non-threaded.
> And I needed to fix the Callback DESTROY #if identation from
> https://github.com/cosimo/perl5-win32-api/pull/6
> non-threaded needs to skip the t/threading_fails.t tests also.
>
> non-threaded:
> $ alias p
> alias p='/usr/local/bin/perl5.16.2d-nt.exe'
> $ alias pb
> alias pb='p -Iblib/arch -Iblib/lib'
> $ pb t/GetContext.pl
> $VAR1 =
> "?\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\177\2\377\377
>
> \0\377\377\377\377\377\377\177\377\24X\e\0\0\0pe-X#\0\377\377\210\225\"\0x\227\"\0\0\0\1\0\0\0(\233\nax\227\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\254\201\1
>
> \25\0\0\0\0\0\0\0\0\0\0\0\0\200\377?\0\0\0\0\374\377\377\377\34\@\0\0\0\0\0\0\0\0;\0\0\0#\0\0\0#\0\0\0_\36\32a\0\0\0\0\300\246\"\0\4\0\0\0\0\0\0\0\270\245\"\0\b\246\"\0\373*\201|\e\0\0\0F\2\0\0\264\245\"\0#\0\0\0\177\2
>
> \0\0\0\0\0\177\377\24X\e\0\0\0pe-X#\0\0\0\200\37\0\0\377\377\0\0\210\225\"\0x\227\"\0\0\0\0\0\0\0\0\0\1\0\0\0(\233\nax\227\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\254\201\1
>
> \25\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\200\377?\0\0\0\0\0\0\0\0\0\0\374\377\377\377\34\@\0\0\0\0\0\0\200\251\"\0_\300\16a#\0;\0\0\0#\0\200\251\"\0_\300\16a#\0;\0\0\0#\0D\377\"\0`\16\240_\0\0__register_frame_info\0\0\252\"\0\0\0\0\0\0\0\0\0\260_'a\0\0\0\0000\0<\0\310\222'a\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\344}\310\16\267_\315\1qG\"\302A\271\315\1>\340\312\16\267_\315\1>\340\312\16\267_\315\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20(\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\nA\202\0\0\0\0\0\0\0\0\0\0\0\0\0
> \224\32a\303\0\0\0
>
> \224\32a\343z\0a\0\0\0\0\0\0\0\0<\246\"\0\234\226\"\0x\227\"\0\1\0\0\0\1\0\0\0\0\1\0\0\270\201\2
>
> \30\230\"\0\@\225\"\0q\230\na#\0;\0\0\0#\0D\377\"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0";
>
> threaded:
> $ alias p
> alias p='perl5.16.2d'
>
> $VAR1 =
> "?\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\177\2\377\377
>
> \0\377\377\377\377\377\377\0\322\26X\e\0\0\0\260t1X#\0\377\377\1\0\0\0(\233\nax\227\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\254\201\1
>
> \25\0\0\0\0\0\20(\0\0\@\0\0\0\377\0\0\0\0\0\0\0\0\200\377?\0\0\0\0\374\377\377\377\34\@\0\0\0\0\0\0\0\0;\0\0\0#\0\0\0#\0\0\0[\36\32a\0\0\0\0\260\246\"\0\4\0\0\0\0\0\0\0\230\245\"\0\350\245\"\0\373*\201|\e\0\0\0F\2\0\0\224\245\"\0#\0\0\0\177\2
>
> \0\0\0\0\0\0\322\26X\e\0\0\0\260t1X#\0\0\0\200\37\0\0\377\377\0\0\1\0\0\0(\233\nax\227\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\254\201\1
>
> \25\0\0\0\0\0\0\0\0\0\0\0\20(\0\0\@\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\200\377?\0\0\0\0\0\0\0\0\0\0\374\377\377\377\34\@\0\0\0\0\0\0D\377\"\0`\16\240_\0\0__regiD\377\"\0`\16\240_\0\0__register_frame_info\0\0\252\"\0\0\0\0\0\0\0\0\0\260_'a\0\0\0\0000\0<\0\@\223'a\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\344}\310\16\267_\315\1qG\"\302A\271\315\1>\340\312\16\267_\315\1>\340\312\16\267_\315\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20(\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\nA\202\0\0\0\0\0\0\0\0\0\0\0\0\0
> \224\32a\303\0\0\0
>
> \224\32a\343z\0a\0\0\0\0\0\0\0\0<\246\"\0\234\226\"\0x\227\"\0\1\0\0\0\1\0\0\0\0\1\0\0\270\201\2
>
> \30\230\"\0\@\225\"\0q\230\na#\0;\0\0\0#\0D\377\"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0";
>
> $ cmp gc-non-thr.xx gc-thr.xx
> gc-non-thr.xx gc-thr.xx differ: byte 107, line 1
>
> --
> Reini Urban
> http://cpanel.net/   http://www.perl-compiler.org/
>
> ___________________________________________________________
>
> Basically the problem is, something is "going wrong" in the x87 FP or
> SSE system when running "denormal" float FP numbers through Jerry's
> cygwin. Looking at the snapshot of the FP regs will reveal what exactly
> is going on, rounding mode, precision, exception masks, other things,
> etc. Comparing Reini's context dump to Jerrys to mine will reveal what
> is going on. The problem is, looking at those registers is sort of
> undocumented, nobody does it except compiler writers. OSes don't care
> about the details about those registers, aslong as they can be saved and
> restored to memory for context switches. I can't find any decent C
> struct definition (including C bitfields of the bitfield registers) of
> the data on Google that the x86 FXSAVE op creates. Also the docs online
> are all copied out of Intel's x86 asm manual, which unintelligibly dry
> for me. I'm a bit stuck right now on this bug.
>

Reply via email to