Skip Menu |

This queue is for tickets about the Win32-API CPAN distribution.

Report information
The Basics
Id: 80322
Status: resolved
Priority: 0/
Queue: Win32-API
People
Owner: Nobody in particular
Requestors: jdhedden [...] cpan.org
Cc: rurban [...] x-ray.at
AdminCc:
Bug Information
Severity: Important
Broken in:
  • 0.72
  • 0.73
Fixed in: (no value)
Attachments
03_Jim_Shaw_good_output.txt
GetContext.pl
JerryGetContext.out

History Show all quoted text
  Sun Oct 21 17:49:07 2012 jdhedden [...] cpan.org - Ticket created
Subject: 'make test' failure - 03_Jim_Shaw.t - invalid unpack type
Show quoted text
> perl -Mblib Callback/t/03_Jim_Shaw.t
1..6 ok 1 - use Win32::API; ok 2 - use Win32::API::Callback; ok 3 - use Win32::API::Test; ok 4 - loaded get_window_pids: Desktop hwnd: 65556 Invalid type '-' in unpack at /var/perl/cpan/build/Win32-API- 0.73/blib/lib/Win32/API/Callback.pm line 188. # Looks like you planned 6 tests but ran 4. # Looks like your test exited with 255 just after 4. Show quoted text
> perl -V
Summary of my perl5 (revision 5 version 16 subversion 1 patch 53802) configuration: Snapshot of: 06d742c02d396d6515581002f376b55ab1972c1b Platform: osname=cygwin, osvers=1.7.16(0.26253), archname=cygwin-thread-multi- 64int uname='cygwin_nt-5.1 med-heddenj 1.7.16(0.26253) 2012-07-20 22:55 i686 cygwin ' config_args='-de -Duse64bitint -Dusethreads -Uusemymalloc - Dinc_version_list=none -Dnoextensions=DB_File Devel/DProf GDBM_File IPC/SysV NDBM_File ODBM_File Sys/Syslog Text/Soundex Time/Piece attrs B/Debug B/Lint -A append:ccflags= -DNO_MATHOMS -A define:optimize=-Os - pipe -funit-at-a-time -march=pentium4 -mfpmath=sse -mieee-fp -mmmx -msse -msse2' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ - DNO_MATHOMS -fno-strict-aliasing -pipe -fstack-protector - I/usr/local/include', optimize='-Os -pipe -funit-at-a-time -march=pentium4 -mfpmath=sse - mieee-fp -mmmx -msse -msse2', cppflags='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -DNO_MATHOMS - fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.5.3', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='g++', ldflags =' -Wl,--enable-auto-import -Wl,--export-all- symbols -Wl,--enable-auto-image-base -s -fstack-protector - L/usr/local/lib' libpth=/usr/local/lib /usr/lib /lib libs=-ldb -ldl -lcrypt perllibs=-ldl -lcrypt libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=cygperl5_16_1.dll gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s' cccdlflags=' ', lddlflags=' --shared -Wl,--enable-auto-import -Wl,- -export-all-symbols -Wl,--enable-auto-image-base -s -L/usr/local/lib - fstack-protector' Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES MULTIPLICITY NO_MATHOMS PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_PRESERVE_IVUV PERL_USE_SAFE_PUTENV USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API Built under cygwin Compiled at Oct 1 2012 10:24:20 %ENV: PERLIO="perlio" CYGWIN="nodosfilewarning" @INC: /usr/lib/perl5/site_perl/5.16.1/cygwin /usr/lib/perl5/site_perl/5.16.1 /usr/lib/perl5/5.16.1/cygwin /usr/lib/perl5/5.16.1 . Let me know if there is more information that you need, or if I can help with testing.
  Sun Oct 21 19:26:42 2012 BULKDD [...] cpan.org - Reference to https://rt.cpan.org/Ticket/Display.html?id=80217#txn-1130807 added
  Sun Oct 21 19:30:47 2012 BULKDD [...] cpan.org - Correspondence added
On Sun Oct 21 17:49:07 2012, JDHEDDEN wrote: Show quoted text
> > perl -Mblib Callback/t/03_Jim_Shaw.t
> 1..6 > ok 1 - use Win32::API; > ok 2 - use Win32::API::Callback; > ok 3 - use Win32::API::Test; > ok 4 - loaded > get_window_pids: Desktop hwnd: 65556 > Invalid type '-' in unpack at /var/perl/cpan/build/Win32-API- > 0.73/blib/lib/Win32/API/Callback.pm line 188.
................................... Show quoted text
> Let me know if there is more information that you need, or if I can help > with testing.
I thought in https://rt.cpan.org/Ticket/Display.html?id=80217#txn-1130807 the problem was solved. Is the fatal error only on Perl 5.16 on Cygwin 1.7 but Perl 5.16 on Cygwin 1.5 is fine? I am preparing a diagnostic release on github to try and figure this one out.
  Sun Oct 21 19:30:49 2012 The RT System itself - Status changed from 'new' to 'open'
  Sun Oct 21 20:03:33 2012 BULKDD [...] cpan.org - Correspondence added
On Sun Oct 21 17:49:07 2012, JDHEDDEN wrote: Show quoted text
> Let me know if there is more information that you need, or if I can help > with testing.
A commit is up for you to try at https://github.com/bulk88/perl5-win32-api/tree/cygwin-revisit-%231 . You might want to hand trim the output of Jim Shaw test for privacy/security reasons. Make sure you indicate where you cut the output.
  Tue Oct 23 08:57:29 2012 jdhedden [...] cpan.org - Correspondence added
Subject: Re: [rt.cpan.org #80322] 'make test' failure - 03_Jim_Shaw.t - invalid unpack type
Date: Tue, 23 Oct 2012 08:56:45 -0400
To: bug-Win32-API [...] rt.cpan.org
From: "Jerry D. Hedden" <jdhedden [...] cpan.org>
On Sun, Oct 21, 2012 at 8:03 PM, Daniel Dragan via RT <bug-Win32-API@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 > > A commit is up for you to try at > https://github.com/bulk88/perl5-win32-api/tree/cygwin-revisit-%231 . You > might want to hand trim the output of Jim Shaw test for privacy/security > reasons. Make sure you indicate where you cut the output.
All tests passed for Perl 5.16.1 under Cygwin 1.5. For Perl 5.16.1 under Cygwin 1.7, the following failure occurs: t/03_Jim_Shaw.t ...... 1/6 $paramcount=4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L $paramcount=4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L $paramcount=4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L $paramcount=4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L $paramcount=4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L $paramcount=4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L $paramcount=4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L $paramcount=-4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L Invalid type '-' in unpack at /c/_/Xfer/bulk88-perl5-win32-api-cdc5668/Callback/../blib/lib/Win32/API/Callback.pm line 190. # Looks like you planned 6 tests but ran 4. # Looks like your test exited with 255 just after 4. t/03_Jim_Shaw.t ...... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 2/6 subtests More fully: Show quoted text
> perl -Mblib Callback/t/03_Jim_Shaw.t
1..6 ok 1 - use Win32::API; ok 2 - use Win32::API::Callback; ok 3 - use Win32::API::Test; ok 4 - loaded $VAR1 = bless( { 'out' => 3, 'outtype' => 'I', 'cdecl' => 0, 'sub' => sub { "DUMMY" }, 'inbytes' => 8, 'intypes' => [ 'N', 'N' ], 'codeExecAlloc' => bless( do{\(my $o = 14229136)}, 'Win32::API::Callback::HeapBlock' ), 'code' => 14229136 }, 'Win32::API::Callback' ); get_window_pids: Desktop hwnd: 65556 $paramcount=4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L window_enumerator - hwnd=[65878], PID=[2780] $paramcount=4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L window_enumerator - hwnd=[65880], PID=[2780] $paramcount=4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L window_enumerator - hwnd=[65706], PID=[1620] $paramcount=4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L window_enumerator - hwnd=[65686], PID=[1620] $paramcount=4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L window_enumerator - hwnd=[65688], PID=[1620] $paramcount=4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L window_enumerator - hwnd=[65704], PID=[1620] $paramcount=4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L window_enumerator - hwnd=[65682], PID=[1620] $paramcount=-4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L Invalid type '-' in unpack at /c/_/Xfer/bulk88-perl5-win32-api-cdc5668/blib/lib/Win32/API/Callback.pm line 190. # Looks like you planned 6 tests but ran 4. # Looks like your test exited with 255 just after 4. (I don't recognize anything in the above as potentially related to privacy/security.)
  Tue Oct 23 19:08:54 2012 BULKDD [...] cpan.org - Correspondence added
On Tue Oct 23 08:57:29 2012, JDHEDDEN wrote: Show quoted text
> All tests passed for Perl 5.16.1 under Cygwin 1.5. For Perl 5.16.1 > under Cygwin 1.7, the following failure occurs:
.................................... Show quoted text
> $paramcount=4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L > window_enumerator - hwnd=[65682], PID=[1620] > $paramcount=-4 $IB=16, $obj->IB=8 PTRSIZE=4 PTRLET=L > Invalid type '-' in unpack at > /c/_/Xfer/bulk88-perl5-win32-api- > cdc5668/blib/lib/Win32/API/Callback.pm > line 190. > # Looks like you planned 6 tests but ran 4. > # Looks like your test exited with 255 just after 4. >
I'm not sure what to do. Basic math is not working randomly (????). Show quoted text
__________________________________________________________ $inbytes = $self->{inbytes}; #first is ebp copy then ret address $inbytes += PTRSIZE * 2; my $paramcount = $inbytes / PTRSIZE ; warn("\$paramcount=$paramcount \$IB=$inbytes, \$obj->IB=". $self->{inbytes}." PTRSIZE=".PTRSIZE." PTRLET=".PTRLET."\n");
__________________________________________________________ $paramcount is supposed to be a positive number. Both $inbytes and PTRSIZE are positive as printed in the warn call. Why did the result of the operation that happened 7 times correctly suddenly become negative? I retried the cygwin fix branch I gave you with my Cygwin Perl and I attached what it looks like when the jim_shaw test succeeds. Towards the end there is a dump of all/some Win32 GUI components and their names (the privacy issues I mentioned). Here is the -V of the Cyg Perl I used.
_________________________________________________________ $ perl -V Summary of my perl5 (revision 5 version 14 subversion 2) configuration: Platform: osname=cygwin, osvers=1.7.15(0.26053), archname=cygwin-thread-multi-64int uname='cygwin_nt-5.1 winxp 1.7.15(0.26053) 2012-05-09 10:25 i686 cygwin '
_________________________________________________________ Did you compile your own CygPerl 5.16 or you are using an official build from Cygnus? I noticed your Perl has
_________________________________________________________ optimize='-Os -pipe -funit-at-a-time -march=pentium4 -mfpmath=sse - mieee-fp -mmmx -msse -msse2',
_________________________________________________________ meanwhile my CygPerl just has
_________________________________________________________ optimize='-O3',
_________________________________________________________ I am running low on ideas on what is causing this. I dont think this is a problem Win32::API, since superficially it does not look like a SEGV, or random memory corruption which are Win32::API's typical failure modes. Just a single bit is wrong in the IV, IF that is an IV. If you compiled your own CygPerl, did it pass a make test when you built it? I can only investigate what is special about your Perl build that caused that division statement to break. My next idea is to add Devel::Peek::Dump on $paramcount before and after the problematic division and see if $paramcount is an IV or NV. After that try to reduce the math division error to a test case that doesn't involve Win32::API. I can not reproduce the Jim Shaw test failure with my Cygnus CygPerl 5.14 How do you want to proceed?
Subject: 03_Jim_Shaw_good_output.txt

Message body is not shown because it is too large.

  Tue Oct 23 19:38:29 2012 jdhedden [...] cpan.org - Correspondence added
Subject: Re: [rt.cpan.org #80322] 'make test' failure - 03_Jim_Shaw.t - invalid unpack type
Date: Tue, 23 Oct 2012 19:37:49 -0400
To: bug-Win32-API [...] rt.cpan.org
From: "Jerry D. Hedden" <jdhedden [...] cpan.org>
Show quoted text
> Did you compile your own CygPerl 5.16 or you are using an official build > from Cygnus?
Yes, I build my own perl, and have been doing so for years. Show quoted text
> If you compiled your own CygPerl, did it pass a make test when you built it?
Yes, it passes 'make test'. If I have failures, I submit bug reports or patches to p5p. Show quoted text
> I can only investigate what is special about your Perl build that caused > that division statement to break. My next idea is to add > Devel::Peek::Dump on $paramcount before and after the problematic > division and see if $paramcount is an IV or NV. After that try to reduce > the math division error to a test case that doesn't involve Win32::API. > I can not reproduce the Jim Shaw test failure with my Cygnus CygPerl 5.14 > > How do you want to proceed?
If you can code up what you want me to run, I'll do it and send back the results. If you want me to do it, I'll try to figure out what you're suggesting and see if I can get it coded up myself. For the back and forth between us, it might be best to email each other directly and not clutter up the bug report. We can put a synopsis of the final outcome when we get there. Just a suggestion. I'll also work on building a 5.14 perl to test this as well. (I was on a hiatus for awhile.)
  Fri Nov 02 10:47:21 2012 jdhedden [...] cpan.org - Correspondence added
On Fri, Nov 2, 2012 at 10:31 AM, bulk 88 <bulk88@hotmail.com> wrote: Show quoted text
> 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.
  Fri Nov 02 10:48:23 2012 jdhedden [...] cpan.org - Cc rurban@x-ray.at added
  Fri Nov 02 17:46:15 2012 rurban [...] x-ray.at - Correspondence added
CC: libwin32 [...] perl.org
Subject: Re: [rt.cpan.org #80322] 'make test' failure - 03_Jim_Shaw.t - invalid unpack type
Date: Fri, 2 Nov 2012 16:46:01 -0500
To: bug-Win32-API [...] rt.cpan.org
From: Reini Urban <rurban [...] x-ray.at>
I checked cygwin perl 5.16.2 non-threaded, fixed on obvious bug, and the tests pass. See https://github.com/cosimo/perl5-win32-api/pull/6 Checking soon with a threaded cygwin perl. On Fri, Nov 2, 2012 at 9:47 AM, Jerry D. Hedden via RT <bug-Win32-API@rt.cpan.org> wrote: Show quoted text
> 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: jdhedden@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 <bulk88@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.
-- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
  Sat Nov 10 22:31:36 2012 BULKDD [...] cpan.org - Correspondence added
RT-Send-CC: libwin32 [...] perl.org, rurban [...] x-ray.at
Attaching private mail for the record. Show quoted text
________________________________
> From: jdhedden@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: bulk88@hotmail.com > CC: rurban@x-ray.at > > Output Attached > > > On Sat, Nov 3, 2012 at 1:38 AM, bulk 88 > <bulk88@hotmail.com<mailto:bulk88@hotmail.com>> wrote: > > > > ----------------------------------------
> > From: jdhedden@cpan.org<mailto:jdhedden@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: bulk88@hotmail.com<mailto:bulk88@hotmail.com> > > CC: rurban@x-ray.at<mailto:rurban@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 <bulk88@hotmail.com> wrote:
> ----------------------------------------
>> From: jdhedden@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: bulk88@hotmail.com >> CC: rurban@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.
Subject: GetContext.pl
use constant ( EXCEPTION_CONTINUE_EXECUTION => 0xffffffff ); use Win32::API qw( ReadMemory ); use Win32::API::Callback; use Data::Dumper; $Data::Dumper::Useqq = 1; my $AddVectoredExceptionHandler = Win32::API->new('kernel32.dll', 'AddVectoredExceptionHandler', 'IK', 'N'); die "bad AddVectoredExceptionHandler" if ! $AddVectoredExceptionHandler; my $RemoveVectoredExceptionHandler = Win32::API->new('kernel32.dll', 'RemoveVectoredExceptionHandler', 'N', 'I'); die "bad RemoveVectoredExceptionHandler" if ! $RemoveVectoredExceptionHandler; my $RaiseException = Win32::API->new('kernel32.dll', 'RaiseException', 'IIIN', 'V'); die "bad RaiseException" if ! $RaiseException; $cb = Win32::API::Callback->new(sub { #not 64bit compliant my $pExceptionInfo = ReadMemory($_[0], 8); my ($pExceptionRecord, $pContextRecord) = unpack('LL', $pExceptionInfo); my $ContextRecord = ReadMemory($pContextRecord, 716); print Dumper($ContextRecord); return EXCEPTION_CONTINUE_EXECUTION; }, 'N', 'i'); die "bad CB" if ! $cb; my $VHHnd; die "AddVectoredExceptionHandler failed" if ! ($VHHnd = $AddVectoredExceptionHandler->Call(1, $cb)); $RaiseException->Call(0,0,0,0); die "RemoveVectoredExceptionHandler failed" if ! $RemoveVectoredExceptionHandler->Call($VHHnd);
Subject: JerryGetContext.out
Download JerryGetContext.out
application/octet-stream 1.6k

Message body not shown because it is not plain text.

  Sun Nov 11 17:13:54 2012 jdhedden [...] cpan.org - Correspondence added
CC: rurban [...] x-ray.at
Subject: Re: [rt.cpan.org #80322] 'make test' failure - 03_Jim_Shaw.t - invalid unpack type
Date: Sun, 11 Nov 2012 17:13:11 -0500
To: bug-Win32-API [...] rt.cpan.org
From: "Jerry D. Hedden" <jdhedden [...] cpan.org>
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-API@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 > > > Attaching private mail for the record. > > ________________________________
> > From: jdhedden@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: bulk88@hotmail.com > > CC: rurban@x-ray.at > > > > Output Attached > > > > > > On Sat, Nov 3, 2012 at 1:38 AM, bulk 88 > > <bulk88@hotmail.com<mailto:bulk88@hotmail.com>> wrote: > > > > > > > > ----------------------------------------
> > > From: jdhedden@cpan.org<mailto:jdhedden@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: bulk88@hotmail.com<mailto:bulk88@hotmail.com> > > > CC: rurban@x-ray.at<mailto:rurban@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 <bulk88@hotmail.com> wrote:
> > ----------------------------------------
> >> From: jdhedden@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: bulk88@hotmail.com > >> CC: rurban@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. >
  Sun Nov 11 23:14:46 2012 BULKDD [...] cpan.org - Correspondence added
RT-Send-CC: libwin32 [...] perl.org, rurban [...] x-ray.at
On Sun Nov 11 17:13:54 2012, JDHEDDEN wrote: Show quoted text
> It is possible this has anything to do with the compiler flags I use: > > -march=pentium4 -mfpmath=sse -mieee-fp -mmmx -msse -msse2 >
Maybe it does. I compared x87 control word, x87 status word, and sse mxcsr. No FP exceptions are allowed to fire on yours or mine (so it is not a cygwin or GCC FP exception handler, I don't think it is). Basically everything is identical (i had a inexact flag on and condition bit C3 was on for me, yours didn't have either on, some other small differences might exist but they weren't signifigant for me to remember). Below is what I used to look at the data. The Reini data is broken (wrong length). Basically, the bug is, your platform fails on division after 7 "return *(float *)"\x01\x00\x00\x00";". What OS/CPU are you using (are you using YMM registers?)? A random fact, x87 has only FP 8 registers. I wonder, if the asm code that is loading the float into the register, is "corrupting" the other 7 registers? I'll have to check another day. I might also try to write a pure C/XS example with the unusual float and a eval_pv with a division operation and see if I trigger it that way. The opcode I used is the same Visual C used when Visual C compiled the following Show quoted text
______________________________________________________ ////the template used in the MakeCB for x86 double CALLBACK CallbackTemplateD() { void (*PerlCallback)(SV *, void *, unsigned __int64 *, FuncRtnCxt *) = 0xC0DE0001; FuncRtnCxt FuncRtnCxtVar; FDUNION retval; PerlCallback((SV *)0xC0DE0002, (void*)0xC0DE0003, (unsigned __int64 *)&retval, &FuncRtnCxtVar); if(FuncRtnCxtVar.F_Or_D){ return (double) retval.f; } else{ return retval.d; } }
_____________________________________________________ void SC(cxts1, cxts2, cxts3) char * cxts1 char * cxts2 char * cxts3 PREINIT: struct FXSAVE { UINT16 _fcw; UINT16 _fsw; UINT8 _ftw; UINT8 _pad1; UINT16 _fop; UINT32 _fpuip; UINT16 _cs; UINT16 _pad2; UINT32 _fpudp; UINT16 _ds; UINT16 _pad3; UINT32 _mxcsr; UINT32 _mxcsrmask; UINT8 _st[8 * 16]; UINT8 _xmm[8 * 16]; UINT8 _pad4[56 * 4]; }; struct _CONTEXT * cxt1 = (struct _CONTEXT *)cxts1; struct _CONTEXT * cxt2 = (struct _CONTEXT *)cxts2; struct _CONTEXT * cxt3 = (struct _CONTEXT *)cxts3; PFLOATING_SAVE_AREA fp1 = &cxt1->FloatSave; PFLOATING_SAVE_AREA fp2 = &cxt2->FloatSave; PFLOATING_SAVE_AREA fp3 = &cxt3->FloatSave; struct FXSAVE * fxs1 = &cxt1->ExtendedRegisters; struct FXSAVE * fxs2 = &cxt2->ExtendedRegisters; struct FXSAVE * fxs3 = &cxt3->ExtendedRegisters; CODE: DebugBreak(); printf("hw\n");
________________________________________________ #Jerry $cxt1 = "?\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\360\234\bX\e\0]\5\270\244\"\0#\0\377\377\0\0\0\0\$\272\224\250\234\372\1\0\0\0\0\0\0\0\0\0\235\377O\200\0\r\333\272\324\271h\\\253\0\274\271\224\250x\240\200f2\213\355\266T\200\31\0\4\e\0\200\300\273\224\250d\275\0h\254\375\235\355Q\240\1\@\0\0\0\0\0\0\0\240\1\@\0\0\0\0\0\0\0\0;\0\0\0#\0\0\0#\0\0\0\4\0\0\0\0\0\0\0h\252\"\0\377\377\377\377\251*\201|\230\250\"\0\350\250\"\0\373*\201|\e\0\0\0F\2\0\0\224\250\"\0#\0\0\0\177\2 \0\0\0]\5\360\234\bX\e\0\0\0\270\244\"\0#\0\0\0\240\37\0\0\377\377\0\0\0\0\0\0\$\272\224\250\234\372\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\235\377O\200\0\r\333\272\324\271\0\0\0\0\0\0h\\\253\0\274\271\224\250x\240\0\0\0\0\0\0\200f2\213\355\266T\200\31\0\0\0\0\0\0\0\4\e\0\200\300\273\224\250d\275\0\0\0\0\0\0\0h\254\375\235\355Q\240\1\@\0\0\0\0\0\0\0\0\0\0\0\0\0\240\1\@\0\0\0\0\0\0X\354\$\0\0\0\0\0\0\0\0\0\0\0\0\0\260\256\n\324b\20\24\@\0\0\0\0\0\0\0\0\0\0\0\0\0\210\303\@\0\0\0\0\0\0\0\0\0\0\0\0\320\273\224\250rG\205\277\0\0\0\0\325\221\0\0\320\273\224\250\255G\205\277\30\222\301\351\$\272\224\250\35H\205\277\0\0\0\1\200\b\22\347\30\222\301\351\b\0\n\0\0\273\224\250p\241M\200x\1\346\271\0\0\2\0\0\340\375\177\@\272\224\250\1\0\0\0\0\1\0\0\20\202\2 \350\227\"\0\20\225\"\0001\234\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\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\16\0\0\0\1\0\0\0\2\0\0\0\1\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0"; #Reini $cxt2 = "?\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"; #Daniel $cxt3 = "?\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 \@\377\377\377\377\377\377\252U\5(\e\0\330\5\0\0\0\0#\0\377\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\n\330\220|\21\264\27\0\0\0L\365\23\0\$\0\1\0\0\0008:\25\0a\264\0\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0D\234\f\@\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\0004B4\0\0\0\0\0\313*\1(\377\377\377\377\@\372\22\0\270\371\22\0\b\372\22\0\373*\201|\e\0\0\0F\2\0\0\264\371\22\0#\0\0\0\177\2 \@\0\0\330\5\252U\5(\e\0\0\0\0\0\0\0#\0\0\0\240\37\0\0\377\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\n\330\220|\21\264\0\0\0\0\0\0\27\0\0\0L\365\23\0\$\0\0\0\0\0\0\0\1\0\0\0008:\25\0a\264\0\0\0\0\0\0\0\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0D\234\f\@\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\0\0\0\0\0\0\20\@\0\0\0\0\0\0\0\0\325x\351&1\b\24\@\0\0\0\0\0\0\0\0*\32k\177g{\204?\0\0\0\0\0\0\0\0\0\0\0\0\0\0\$\@\0\0\0\0\0\0\0\0\215\265\277\263=\n\24\@\0\0\0\0\0\0\0\0^\324\301w\265\1\0\0\t\0\0\0\237\370\23\0\1\0\0\0P\366\23\0\1\0\0\0\237\370\23\0\237\370\23\0\210\366\23\0%\20\304w\243\324\301w\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"; $cxt2 = "\x00" x 716; die "bad len".length($cxt1) if length($cxt1) != 716; die "bad len".length($cxt2) if length($cxt2) != 716; die "bad len".length($cxt3) if length($cxt3) != 716; Local::XS::SC($cxt1, $cxt2, $cxt3);
  Thu Jan 21 15:49:36 2016 BULKDD [...] cpan.org - Correspondence added
After having no clue how to fix this, and having some doubts if this ticket is real, I reproduced it with Win 7+VC 2013. Perhaps something in EnumChildWindows changed between Win XP and Win7 that stopped "resetting" the FPU, or the SSE heavy instead of x87, machine code of VC 2013 wasn't clearing the FPU state the way the older non-SSE code wouldve, or EnumChildWindows in WinXP used ebp as base pointer and in Win7 when MS compiled user32.dll, ebp was reused as GPR with only esp addressing. Anyways, what was happening was each fld op in the shellcode callback was pushing one var onto FPU stack. Eventually the FPU stack which has 8 elements was filled. x87 Stack Fault (bit 6) exception bit came on at that point. After that, no further FPU math was possible. NAN was the result of every op. That resulted in this PP division op failing, after 8 calls of the W::A::C callback https://metacpan.org/source/BULKDD/Win32-API-0.82/Callback.pm#L176 this line in PP was returning NAN even though its "16/4" which cant possibly be NAN. The NAN in a SVNV after going through SvUV became 0, so the callback unwound the C stack by 0 bytes instead of 8 as stdcall requires (EnumChildWindows wants a stdcall func, not cdecl). Eventually EnumChildWindows poped nonvol register esi from the wrong location on C stack a couple hundred bytes away from the correct location of the saved esi register, since every call into the callback screwed up esp by 8 bytes. The corrupted esi register after EnumChildWindows returned control to W::A causing a crash in Win32::API's Call_asm.
  Thu Jan 21 15:49:49 2016 BULKDD [...] cpan.org - Status changed from 'open' to 'resolved'
  Thu Jan 21 15:49:50 2016 BULKDD [...] cpan.org - Fixed in 0.84 added
  Thu Jan 21 17:02:33 2016 TONYC [...] cpan.org - Correspondence added
On Thu Jan 21 15:49:36 2016, BULKDD wrote: Show quoted text
> After having no clue how to fix this, and having some doubts if this > ticket is real, I reproduced it with Win 7+VC 2013. Perhaps something > in EnumChildWindows changed between Win XP and Win7 that stopped > "resetting" the FPU, or the SSE heavy instead of x87, machine code of > VC 2013 wasn't clearing the FPU state the way the older non-SSE code > wouldve, or EnumChildWindows in WinXP used ebp as base pointer and in > Win7 when MS compiled user32.dll, ebp was reused as GPR with only esp > addressing. > > Anyways, what was happening was each fld op in the shellcode callback > was pushing one var onto FPU stack. Eventually the FPU stack which has > 8 elements was filled. x87 Stack Fault (bit 6) exception bit came on > at that point. After that, no further FPU math was possible. NAN was > the result of every op. That resulted in this PP division op failing, > after 8 calls of the W::A::C callback > https://metacpan.org/source/BULKDD/Win32-API-0.82/Callback.pm#L176 > this line in PP was returning NAN even though its "16/4" which cant > possibly be NAN. The NAN in a SVNV after going through SvUV became 0, > so the callback unwound the C stack by 0 bytes instead of 8 as stdcall > requires (EnumChildWindows wants a stdcall func, not cdecl). > Eventually EnumChildWindows poped nonvol register esi from the wrong > location on C stack a couple hundred bytes away from the correct > location of the saved esi register, since every call into the callback > screwed up esp by 8 bytes. The corrupted esi register after > EnumChildWindows returned control to W::A causing a crash in > Win32::API's Call_asm.
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. 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. Tony
  Thu Jan 21 17:02:35 2016 TONYC [...] cpan.org - Fixed in 0.84 deleted
  Thu Jan 21 20:17:53 2016 BULKDD [...] cpan.org - Correspondence added
On Thu Jan 21 17:02:33 2016, TONYC wrote: Show quoted text
> 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. Show quoted text
> 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.