Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[rt.cpan.org #80322] 'make test' failure - 03_Jim_Shaw.t - invalid unpack type
4 views
Skip to first unread message
Jerry D. Hedden via RT
Oct 21, 2012, 5:49:08 PM10/21/12
to libw...@perl.org
Sun Oct 21 17:49:07 2012: Request 80322 was acted upon.
Transaction: Ticket created 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: jdhe...@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
> 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.
> 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.
Transaction: Ticket created 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: jdhe...@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
> 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.
> 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.
Daniel Dragan via RT
Oct 21, 2012, 7:30:49 PM10/21/12
to libw...@perl.org
Sun Oct 21 19:30:47 2012: Request 80322 was acted upon.
Transaction: Correspondence added by BULKDD
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.
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: jdhe...@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
Subject: 'make test' failure - 03_Jim_Shaw.t - invalid unpack type
Broken in: 0.72, 0.73
Severity: Important
Owner: Nobody
Requestors: jdhe...@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
On Sun Oct 21 17:49:07 2012, JDHEDDEN wrote:
> > 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.
...................................
> > 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.
> Let me know if there is more information that you need, or if I can help
> with testing.
I thought in
> with testing.
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.
Daniel Dragan via RT
Oct 21, 2012, 8:03:34 PM10/21/12
to libw...@perl.org
Sun Oct 21 20:03:33 2012: Request 80322 was acted upon.
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.
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: jdhe...@cpan.org
Status: open
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: jdhe...@cpan.org
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
On Sun Oct 21 17:49:07 2012, JDHEDDEN wrote:
> 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
On Sun Oct 21 17:49:07 2012, JDHEDDEN wrote:
> Let me know if there is more information that you need, or if I can help
> with testing.
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.
Jerry D. Hedden via RT
Oct 23, 2012, 8:57:30 AM10/23/12
to libw...@perl.org
Tue Oct 23 08:57:29 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
<bug-Wi...@rt.cpan.org> wrote:
> <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
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
line 190.
Failed 2/6 subtests
More fully:
> 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
line 190.
privacy/security.)
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: jdhe...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
On Sun, Oct 21, 2012 at 8:03 PM, Daniel Dragan via RT
Severity: Important
Owner: Nobody
Requestors: jdhe...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
<bug-Wi...@rt.cpan.org> wrote:
> <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
> 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.
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)
# Looks like your test exited with 255 just after 4.
Failed 2/6 subtests
More fully:
> 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
'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
# Looks like your test exited with 255 just after 4.
privacy/security.)
Daniel Dragan via RT
Oct 23, 2012, 7:08:55 PM10/23/12
to libw...@perl.org
Tue Oct 23 19:08:54 2012: Request 80322 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: 'make test' failure - 03_Jim_Shaw.t - invalid unpack type
__________________________________________________________
$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
_________________________________________________________
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?
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: jdhe...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
Severity: Important
Owner: Nobody
Requestors: jdhe...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
On Tue Oct 23 08:57:29 2012, JDHEDDEN wrote:
> 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:
....................................
> 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:
> $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
> 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 (????).
> # Looks like you planned 6 tests but ran 4.
> # Looks like your test exited with 255 just after 4.
>
__________________________________________________________
$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',
_________________________________________________________
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?
Jerry D. Hedden via RT
Oct 23, 2012, 7:38:30 PM10/23/12
to libw...@perl.org
Tue Oct 23 19:38:29 2012: Request 80322 was acted upon.
> 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.
> 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.)
Transaction: Correspondence added by JDHEDDEN
Queue: Win32-API
Subject: Re: [rt.cpan.org #80322] 'make test' failure - 03_Jim_Shaw.t - invalid unpack type
Queue: Win32-API
Broken in: 0.72, 0.73
Severity: Important
Owner: Nobody
Requestors: jdhe...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
Severity: Important
Owner: Nobody
Requestors: jdhe...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
> 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.
> from Cygnus?
> If you compiled your own CygPerl, did it pass a make test when you built it?
or patches to p5p.
> 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?
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.)
Jerry D. Hedden via RT
Nov 2, 2012, 10:47:23 AM11/2/12
to libw...@perl.org
Fri Nov 02 10:47:21 2012: Request 80322 was acted upon.
> 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.
Transaction: Correspondence added by JDHEDDEN
Queue: Win32-API
Subject: 'make test' failure - 03_Jim_Shaw.t - invalid unpack type
Queue: Win32-API
Broken in: 0.72, 0.73
Severity: Important
Owner: Nobody
Requestors: jdhe...@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:
Severity: Important
Owner: Nobody
Requestors: jdhe...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
> 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
Nov 2, 2012, 5:46:01 PM11/2/12
to bug-Wi...@rt.cpan.org, libw...@perl.org
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.
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/
the tests pass.
See https://github.com/cosimo/perl5-win32-api/pull/6
Checking soon with a threaded cygwin perl.
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/
Reini Urban via RT
Nov 2, 2012, 5:46:17 PM11/2/12
to libw...@perl.org
Fri Nov 02 17:46:15 2012: Request 80322 was acted upon.
Transaction: Correspondence added by rur...@x-ray.at
Queue: Win32-API
Subject: Re: [rt.cpan.org #80322] 'make test' failure - 03_Jim_Shaw.t - invalid unpack type
Transaction: Correspondence added by rur...@x-ray.at
Queue: Win32-API
Subject: Re: [rt.cpan.org #80322] 'make test' failure - 03_Jim_Shaw.t - invalid unpack type
Reini Urban
Nov 5, 2012, 10:39:57 AM11/5/12
to bulk 88, libw...@perl.org
On Sat, Nov 3, 2012 at 12:38 AM, bulk 88 <bul...@hotmail.com> wrote:
> ----------------------------------------
>> From: jdhe...@cpan.org
>> Date: Fri, 2 Nov 2012 10:44:05 -0400
>> 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
> ----------------------------------------
>> From: jdhe...@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
Jerry D. Hedden via RT
Nov 11, 2012, 5:13:55 PM11/11/12
to libw...@perl.org
Sun Nov 11 17:13:54 2012: Request 80322 was acted upon.
-march=pentium4 -mfpmath=sse -mieee-fp -mmmx -msse -msse2
On Sat, Nov 10, 2012 at 10:31 PM, Daniel Dragan via RT <
> Attaching private mail for the record.
>
> ________________________________
> > From: jdhe...@cpan.org
> > Date: Tue, 6 Nov 2012 12:50:49 -0500
> > > CC: rur...@x-ray.at<mailto:rur...@x-ray.at>
> ___________________________________________________________
>
> 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.
>
Transaction: Correspondence added by JDHEDDEN
Queue: Win32-API
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: jdhe...@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:
Severity: Important
Owner: Nobody
Requestors: jdhe...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
-march=pentium4 -mfpmath=sse -mieee-fp -mmmx -msse -msse2
> Attaching private mail for the record.
>
> ________________________________
> > From: jdhe...@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
> > invalid unpack type
> > To: bul...@hotmail.com
> > CC: rur...@x-ray.at
> >
> >
> >
> > On Sat, Nov 3, 2012 at 1:38 AM, bulk 88
> > <bul...@hotmail.com<mailto:bul...@hotmail.com>> wrote:
> >
> >
> >
> > ----------------------------------------
> > > From: jdhe...@cpan.org<mailto:jdhe...@cpan.org>
> >
> > On Sat, Nov 3, 2012 at 1:38 AM, bulk 88
> > <bul...@hotmail.com<mailto:bul...@hotmail.com>> wrote:
> >
> >
> >
> > ----------------------------------------
> > > 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
> > > 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?
> >
>
>
> 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.
>
Daniel Dragan via RT
Nov 11, 2012, 11:14:47 PM11/11/12
to libw...@perl.org
Sun Nov 11 23:14:46 2012: Request 80322 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: 'make test' failure - 03_Jim_Shaw.t - invalid unpack type
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
______________________________________________________
////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\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 =
$cxt3 =
\@\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);
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: jdhe...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
Severity: Important
Owner: Nobody
Requestors: jdhe...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
On Sun Nov 11 17:13:54 2012, JDHEDDEN wrote:
> 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
> It is possible this has anything to do with the compiler flags I use:
>
> -march=pentium4 -mfpmath=sse -mieee-fp -mmmx -msse -msse2
>
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
______________________________________________________
////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
\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";
$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);
Daniel Dragan via RT
Nov 11, 2012, 11:14:47 PM11/11/12
to libw...@perl.org, rur...@x-ray.at
Daniel Dragan via RT
Jan 21, 2016, 4:00:02 PM1/21/16
to libw...@perl.org
Thu Jan 21 15:49:36 2016: Request 80322 was acted upon.
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 E
numChildWindows returned control to W::A causing a crash in Win32::API's Call_asm.
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: jdhe...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
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.
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: jdhe...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
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 E
numChildWindows returned control to W::A causing a crash in Win32::API's Call_asm.
TONYC via RT
Jan 21, 2016, 5:15:02 PM1/21/16
to libw...@perl.org
Thu Jan 21 17:02:33 2016: Request 80322 was acted upon.
Transaction: Correspondence added by TONYC
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
On Thu Jan 21 15:49:36 2016, BULKDD wrote:
> 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
Transaction: Correspondence added by TONYC
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: jdhe...@cpan.org
Status: resolved
Subject: 'make test' failure - 03_Jim_Shaw.t - invalid unpack type
Broken in: 0.72, 0.73
Severity: Important
Owner: Nobody
Requestors: jdhe...@cpan.org
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
On Thu Jan 21 15:49:36 2016, BULKDD wrote:
> 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
> 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
Daniel Dragan via RT
Jan 21, 2016, 8:30:02 PM1/21/16
to libw...@perl.org
Thu Jan 21 20:17:53 2016: Request 80322 was acted upon.
Transaction: Correspondence added by BULKDD
> 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.
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: jdhe...@cpan.org
Status: resolved
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80322 >
Subject: 'make test' failure - 03_Jim_Shaw.t - invalid unpack type
Broken in: 0.72, 0.73
Severity: Important
Owner: Nobody
Requestors: jdhe...@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.
> 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.
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.
0 new messages