Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

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

Report information
The Basics
Id: 31609
Status: resolved
Priority: 0/
Queue: Win32-GUI

People
Owner: robertmay [...] cpan.org
Requestors: jdhedden [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in:
  • 1.06
  • 1.05
Fixed in: (no value)



Subject: Negative addresses
During 'make test', this test: is($W->{-accel}, $C->{-handle}, "Accelerator handle stored in parent"); failed as follows: t/05_AcceleratorTable................ # Failed test 'Accelerator handle stored in parent' # at t/05_AcceleratorTable.t line 35. # got: '-324075415' # expected: '3970891881' # Looks like you failed 1 test of 4. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/4 subtests The negative value is a signed 32-bit int representation of the positive value. This indicates some sort of casting error.
On Mon Dec 17 15:48:47 2007, JDHEDDEN wrote: Show quoted text
> During 'make test', this test: > > is($W->{-accel}, $C->{-handle}, "Accelerator handle stored in parent"); > > failed as follows: > > t/05_AcceleratorTable................ > # Failed test 'Accelerator handle stored in parent' > # at t/05_AcceleratorTable.t line 35. > # got: '-324075415' > # expected: '3970891881' > # Looks like you failed 1 test of 4. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/4 subtests > > The negative value is a signed 32-bit int representation of > the positive value. This indicates some sort of casting > error.
Could you provide me details of you build environment (esp. is this a 64-bit environment?) Thanks, Rob.
From: jdhedden [...] cpan.org
Show quoted text
> Could you provide me details of you build environment (esp. is this a > 64-bit environment?)
I use Perl 5.10.0 under Cygwin on Windows XP. Show quoted text
> perl -V
Summary of my perl5 (revision 5 version 10 subversion 0 patch 33007) configuration: Platform: osname=cygwin, osvers=1.5.25(0.15642), archname=cygwin-thread-multi-64int uname='cygwin_nt-5.1 seymour 1.5.25(0.15642) 2007-12-14 19:21 i686 cygwin ' config_args='-de -Duse64bitint -Dusethreads -Uusemymalloc -Uusemallocwrap -Dinc_version_list=none -Dnoextensions=attrs IPC/SysV Sys/Syslog Devel/DProf Devel/Peek re Text/Soundex Math/BigInt/FastCalc Time/Piece -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', 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' ccversion='', gccversion='3.4.4 (cygming special, gdc 0.12, using dmd 0.125)', 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,--stack,8388608 -Wl,--enable-auto-image-base -Wl,--enable-auto-import -s -L/usr/local/lib' libpth=/usr/local/lib /usr/lib /lib libs=-ldl -lcrypt perllibs=-ldl -lcrypt libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a 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,--stack,8388608 -Wl,--enable-auto-image-base -Wl,--enable-auto-import -s -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY NO_MATHOMS PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_USE_SAFE_PUTENV USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Locally applied patches: MAINT Built under cygwin Compiled at Jan 19 2008 11:19:23 %ENV: PERLIO="perlio" CYGWIN="ntsec" @INC: /usr/lib/perl5/5.10.0/cygwin /usr/lib/perl5/5.10.0 .
On Sun Jan 27 11:30:42 2008, JDHEDDEN wrote: Show quoted text
> I use Perl 5.10.0 under Cygwin on Windows XP.
Show quoted text
> Compile-time options: MULTIPLICITY NO_MATHOMS PERL_DONT_CREATE_GVSV > PERL_IMPLICIT_CONTEXT PERL_USE_SAFE_PUTENV > USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES > USE_PERLIO USE_REENTRANT_API
I suspect that USE_64_BIT_INT is the problem. The Win32::GUI codebase is littered with careless casts between HANDLEs (pointers) and IVs. We usually get away with it where IVs are the same size as pointers .... I'm not really sure where to start with this one, as it really needs a complete sweep of the codebase in an atomic manner (I could probably fix this one occurance, but that would only be hiding the problem). Let me try and get a suitable cygwin environment set up and think on this some more .... Rob.
Subject: [PATCH] Negative addresses
The attached patch doesn't fix the underlying 32-bit/64-bit issue, but it does allow the test to pass by converting the addresses to hex and then comparing them.
# http://rt.cpan.org/Ticket/Display.html?id=31609 --- Win32-GUI/t/05_AcceleratorTable.t +++ Win32-GUI/t/05_AcceleratorTable.t @@ -1,4 +1,4 @@ -#!perl -wT +#!perl -w # Win32::GUI test suite. # $Id: 05_AcceleratorTable.t,v 1.2 2006/05/16 18:57:26 robertemay Exp $ # @@ -32,8 +32,8 @@ $W->Change(-accel => $C, ); -is($W->{-accel}, $C->{-handle}, "Accelerator handle stored in parent"); - +is(substr(sprintf('%x', $W->{-accel}), -8), + substr(sprintf('%x', $C->{-handle}), -8), "Accelerator handle stored in parent"); $C->DESTROY(); TODO: {
From: robertmay [...] cpan.org
On Tue Feb 26 20:39:03 2008, JDHEDDEN wrote: Show quoted text
> The attached patch doesn't fix the underlying 32-bit/64-bit issue, but > it does allow the test to pass by converting the addresses to hex and > then comparing them.
Many thanks - that seems like a workable solution for now. I may be missing something, but why do we need the substr()? Isn't is(sprintf('%u', $W->{-accel}), sprintf('%u', $C->{-handle}), "Accelerator handle stored in parent"); enough?
Subject: Re: [rt.cpan.org #31609] Negative addresses
Date: Thu, 28 Feb 2008 09:59:38 -0500
To: bug-Win32-GUI [...] rt.cpan.org
From: "Jerry D. Hedden" <jdhedden [...] cpan.org>
Show quoted text
> is(sprintf('%u', $W->{-accel}), sprintf('%u', $C->{-handle}), > "Accelerator handle stored in parent");
This doesn't work for 64-bit ints. For instance, I got the following failure with the original test code: # Failed test 'Accelerator handle stored in parent' # at t/05_AcceleratorTable.t line 35. # got: '-432340103' # expected: '3862627193' If I put these numbers into the above: is(sprintf('%u', -432340103), sprintf('%u', 3862627193), "Accelerator handle stored in parent"); It fails: # Failed test 'Accelerator handle stored in parent' # at t/05_AcceleratorTable.t line 36. # got: '18446744073277211513' # expected: '3862627193'
From: robertmay [...] cpan.org
On Thu Feb 28 10:00:25 2008, JDHEDDEN wrote: Show quoted text
> > is(sprintf('%u', $W->{-accel}), sprintf('%u', $C->{-handle}), > > "Accelerator handle stored in parent");
> > This doesn't work for 64-bit ints.
Show quoted text
> is(sprintf('%u', -432340103), sprintf('%u', 3862627193), > "Accelerator handle stored in parent"); > > It fails: > > # Failed test 'Accelerator handle stored in parent' > # at t/05_AcceleratorTable.t line 36. > # got: '18446744073277211513' > # expected: '3862627193'
Ah. On reading the report of you system properly I see that it's a 32-bit winXP running Cygwin with 64-bit IVs. I had been looking for problems with 64-bit windows .... on reflection I think that reviewing the whole code-base, as resolving all the dubious casting is probably in order, as on a quick inspection we can expect to see lots of problems like this (and probably even more with 64-bit Windows). This particular failure is (I think - haven't had time to test yet) caused by line 82 of Window.xs which looks like this: storing = newSViv((LONG) handle_From(NOTXSCALL value)); and should be storing = newSViv(PTR2IV(handle_From(NOTXSCALL value))); With 32-bit pointers, the cast of HANDLE(or PVOID, 32-bits) to IV(64-bits) (via type LONG) causes sign-extension of the pointer. And on a machine with 64-bit pointers will lose the top 32-bits of the pointer. There is lots of code like this and it needs fixing. (of course, on machines where the size of a pointer is the same as the size of an IV is the same as the size of a LONG it won't matter). I'll leave this report open until I get to a release in which it is fixed. Would I be right in assuming that the failure is not repeatable, but only happens occasionally? I have a couple of CPAN-testers reports of success in similar environments. Thanks for the report. Rob.
Subject: Re: [rt.cpan.org #31609] Negative addresses
Date: Mon, 3 Mar 2008 13:22:54 -0500
To: bug-Win32-GUI [...] rt.cpan.org
From: "Jerry D. Hedden" <jdhedden [...] cpan.org>
Show quoted text
> Would I be right in assuming that the failure is not repeatable, but > only happens occasionally?
Correct. It happens intermittently. (And I think it will only happen on machines that have more than 2 GB of memory.)
should be fixed in 1.08