Wed Oct 17 13:55:55 2012: Request 80217 was acted upon.
Transaction: Correspondence added by BULKDD
       Queue: Win32-API
     Subject: Build failure under Cygwin on Windows
   Broken in: 0.72
    Severity: Critical
       Owner: Nobody
  Requestors: jdhed...@cpan.org
      Status: open
 Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80217 >


On Wed Oct 17 11:48:44 2012, rur...@x-ray.at wrote:
> I can fully reproduce the errors.

As you said on IRC the problem is alloca. I installed a Cygwin Perl.

$ 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 '
    config_args='-de -Dlibperl=cygperl5_14.dll -Dcc=gcc-4 -Dld=g++-4
-Darchname=i686-cygwin-threads-64int -Dmksymlinks -Dusethreads -Accflags=-g'
    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-4', ccflags ='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -g
-fno-strict-aliasing -pipe -fstack-protector',
    optimize='-O3',
    cppflags='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -g
-fno-strict-aliasing -pipe -fstack-protector'
    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++-4', ldflags =' -Wl,--enable-auto-import
-Wl,--export-all-symbols -Wl,--enable-auto-image-base -fstack-protector
-L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib /lib
    libs=-lgdbm -ldb -ldl -lcrypt -lgdbm_compat
    perllibs=-ldl -lcrypt
    libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=cygperl5_14.dll
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags=' --shared  -Wl,--enable-auto-import
-Wl,--export-all-symbols -Wl,--enable-auto-image-base -L/usr/local/lib
-fstack-protector'


Characteristics of this binary (from libperl):
  Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
                        PERL_IMPLICIT_CONTEXT PERL_PRESERVE_IVUV
                        PERL_USE_SAFE_PUTENV USE_64_BIT_INT USE_ITHREADS
                        USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF
                        USE_REENTRANT_API
  Locally applied patches:
        Bug#55162 File::Spec::case_tolerant performance
        CYG07 $vendorarch/auto/.rebase
        CYG15 static Win32CORE
        CYG17 cyg-1.7 paths-utf8
        0c612ce82 Fix building static extensions on cygwin, -UUSEIMPORTLIB
        1bac5ecc1 Fix 64-bit threading sv.c: S_anonymise_cv_maybe
        Cygwin::sync_winenv added
  Built under cygwin
  Compiled at Jul 12 2012 14:17:21
  %ENV:
    PERL_JSON_BACKEND="JSON::XS"
    PERL_YAML_BACKEND="YAML"
    CYGWIN="tty"
  @INC:
    /usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int
    /usr/lib/perl5/site_perl/5.14
    /usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int
    /usr/lib/perl5/vendor_perl/5.14
    /usr/lib/perl5/5.14/i686-cygwin-threads-64int
    /usr/lib/perl5/5.14
    /usr/lib/perl5/site_perl/5.10
    /usr/lib/perl5/vendor_perl/5.10
    /usr/lib/perl5/site_perl/5.8
    .

I got the same SEGV as others in this ticket said on benchmark.t. The
bug is limited to C funcs that Win32::API calls, that have more than 0
parameters, so this
https://metacpan.org/source/COSIMO/Win32-API-0.72/t/00_API.t#L46 didn't
crash, but 95% of everything else did. I used a assembly debugger (it
was faster for me, too much time to modify makefile.pl to include gdb
symbols), and what I think is the static linked in the DLL alloca,
returned in EAX (return value of alloca), the return instruction address
to right after the CALL alloca opcode, not a pointer to somewhere
near/in the C stack. The bug is towards the end of alloca since the
former return IP is read from the C stack into eax, then eax is pushed
on the c stack, then a retn to return. EAX now contains the return
instructionaddress (0x6E9E2772) while EBP is 0022AA48 and ESP is
0022A960 right before the retn opcode. This is a code generation problem
with Cygwin, not a problem with Win32::API. Here is what I think is
alloca is

6E9E4020 51               push        ecx  ; save ecx
6E9E4021 8D 4C 24 08      lea         ecx,[esp+8] 
6E9E4025 3D 00 10 00 00   cmp         eax,1000h 
6E9E402A 72 15            jb          6E9E4041 
6E9E402C 81 E9 00 10 00 00 sub         ecx,1000h 
6E9E4032 83 09 00         or          dword ptr [ecx],0 
6E9E4035 2D 00 10 00 00   sub         eax,1000h 
6E9E403A 3D 00 10 00 00   cmp         eax,1000h 
6E9E403F 77 EB            ja          6E9E402C 
6E9E4041 29 C1            sub         ecx,eax 
6E9E4043 83 09 00         or          dword ptr [ecx],0 
6E9E4046 89 E0            mov         eax,esp ;move orig esp to eax, our
new mem block
6E9E4048 89 CC            mov         esp,ecx ;move new sp to esp
6E9E404A 8B 08            mov         ecx,dword ptr [eax]; restore ecx
from 6E9E4020
6E9E404C 8B 40 04         mov         eax,dword ptr [eax+4] ;ret addr to
eax, and trash alloca-ed pointer
6E9E404F 50               push        eax ;push eax on stack
6E9E4050 C3               ret             ;pop off stack and jmp

Reply via email to