[rt.cpan.org #80322] 'make test' failure - 03_Jim_Shaw.t - invalid unpack type

[Daniel Dragan via RT]

<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.

GetContext.pl
Description: Binary data

JerryGetContext.out
Description: Binary data