Perl 5.005_62 and Win32::OLE 0.1101

[p5pRT]

Migrated from rt.perl.org#1767 (status was 'resolved')

Searchable as RT1767$

[p5pRT]

From gustav@morpheus.demon.co.uk

Building Win32​::OLE 0.1101 with Perl 5.005_62 (NT4SP5, VC6SP3) I
get an Application Error in t/3_ole.t (code referening memory at
0x0000001c).

The test uses Excel, and I have Excel 2000 installed, so there
may be a version issue, but I have put trace print statements
into the code, and it looks like the problem occurs sometime
while Win32​::OLE​::Const is being *loaded*, but before the import
subroutine is run.

The only nontrivial code I can see which is run when the module is
required, is my $Typelibs = __PACKAGE__->_Typelibs();

I put a croak() at the start of the _Typelibs() code, and the
crash still occurred (ie, it occurred before the croak).

I now don't know what is likely to be the problem...

Some other notes​:

1. PERL_INTERNAL_GLOB requires my Win32 patches. Otherwise,
  MakeMaker breaks - it generates TEST_FILES = t*.t, which
  presumably came from t\*.t with the \ "quoting" the *.

2. My initial build had Sarathy's STOP block patch and my
  File​::Glob patch included. Taking these out made no difference.
  (beyond the fact that nmake test failed to work, as I
  mentioned above).

3. I rebuilt with USE_BINMODE_SCRIPTS removed. That made no
  difference...

Perl Info

Site configuration information for perl 5.00562:

Configured by Administrator at Tue Nov  9 22:00:15 1999.

Summary of my perl5 (revision 5.0 version 5 subversion 62) configuration:
  Platform:
    osname=MSWin32, osvers=4.0, archname=MSWin32-x86
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    usethreads=undef useperlio=undef d_sfio=undef
    use64bits=undef usemultiplicity=undef
  Compiler:
    cc='cl', optimize='-O1 -MD -DNDEBUG', gccversion=
    cppflags='-DWIN32'
    ccflags ='-O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT  -DPERL_INTERNAL_GLOB -DUSE_BINMODE_SCRIPTS'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
    alignbytes=8, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='link', ldflags ='-nologo -nodefaultlib -release  -libpath:"E:\Applications\DevPerl\lib\MSWin32-x86\CORE"  -machine:x86'
    libpth=D:\VisualStudio\VC98\lib
    libs=-DELAYLOAD:wsock32.dll delayimp.lib E:\CDs\General\Libraries\Lib\MD\libdes.lib  oldnames.lib kernel32.lib user32.lib
gdi32.lib  winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib  oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib
winmm.lib  version.lib odbc32.lib odbccp32.lib PerlCRT.lib
    libc=PerlCRT.lib, so=dll, useshrplib=yes, libperl=perl.lib
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ',
ddlflags='-dll -nologo -nodefaultlib -release  -libpath:"E:\Applications\DevPerl\lib\MSWin32-x86\CORE"  -machine:x86'

Locally applied patches:



@INC for perl 5.00562:
    E:/Applications/DevPerl/lib/MSWin32-x86
    E:/Applications/DevPerl/lib
    E:/Applications/DevPerl/site/lib/MSWin32-x86
    E:/Applications/DevPerl/site/lib
    .


Environment for perl 5.00562:
    HOME (unset)
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)

PATH=D:\WINNT\system32;D:\WINNT;D:\NTRESKIT;D:\VisualStudio\Common\Tools\WinNT;D:\VisualStudio\Common\MSDev98\Bin;D:\VisualStudio\Co
mmon\Tools;D:\VisualStudio\VC98\bin;D:\UTILS;E:\Applications\DevPerl\bin;E:\Applications\DevPerl\bin\MSWin32-x86;E:\Oracle\Ora81\bin
;D:\Program Files\Oracle\jre\1.1.7\bin
    PERL_BADLANG (unset)
    SHELL (unset)

[p5pRT]

From @jandubois

On Wed, 10 Nov 1999 21​:46​:46 -0000, "Paul Moore"
<gustav@​morpheus.demon.co.uk> wrote​:

This is a bug report for perl from gustav@​morpheus.demon.co.uk,
generated with the help of perlbug 1.27 running under perl 5.00562.

Please don't send bug reports for non-core modules to p5p but to the
individual authors instead. CC'ing bug reports for modules included in
libwin32 to Perl-Win32-Porters is ok though.

-----------------------------------------------------------------
[Please enter your report here]

Building Win32​::OLE 0.1101 with Perl 5.005_62 (NT4SP5, VC6SP3) I
get an Application Error in t/3_ole.t (code referening memory at
0x0000001c).

The error happens during compilation of the Win32​::OLE​::Const module. The
culprit is the sort code. I've narrowed down the failing code to this​:

  perl -e "sort{my $c;return $a <=> $b}(1,3,2)"

but don't have time to investigate this further right now. It is
essential that the sort function contains a lexical variable and that it
uses an explicit return statement. The crash happens in Perl_peep when
looking at the OP_RETURN​: o->op_next is NULL therefore
o->op_next->op_type is invalid​:

  case OP_RETURN​:
  if (o->op_next->op_type != OP_LEAVESUBLV) {
  o->op_seq = PL_op_seqmax++;
  break;
  }

-Jan

[p5pRT]

From @gsar

On Fri, 12 Nov 1999 20​:53​:51 +0100, Jan Dubois wrote​:

Building Win32​::OLE 0.1101 with Perl 5.005_62 (NT4SP5, VC6SP3) I
get an Application Error in t/3_ole.t (code referening memory at
0x0000001c).

The error happens during compilation of the Win32​::OLE​::Const module. The
culprit is the sort code. I've narrowed down the failing code to this​:

perl -e "sort{my $c;return $a <=> $b}(1,3,2)"

but don't have time to investigate this further right now. It is
essential that the sort function contains a lexical variable and that it
uses an explicit return statement. The crash happens in Perl_peep when
looking at the OP_RETURN​: o->op_next is NULL therefore
o->op_next->op_type is invalid​:

   case OP\_RETURN​:
       if \(o\->op\_next\->op\_type \!= OP\_LEAVESUBLV\) \{
           o\->op\_seq = PL\_op\_seqmax\+\+;
           break;
       \}

This looks like something I fixed a few weeks back.

Sarathy
gsar@​ActiveState.com

Inline Patch

-----------------------------------8<-----------------------------------
Change 4417 by gsar@auger on 1999/10/20 23:45:03

	avoid coredump on C<sort { my $c; return $a cmp $b } ...>

Affected files ...

... //depot/perl/op.c#204 edit

Differences ...

==== //depot/perl/op.c#204 (text) ====
Index: perl/op.c
--- perl/op.c.~1~	Wed Oct 20 16:45:08 1999
+++ perl/op.c	Wed Oct 20 16:45:08 1999
@@ -6187,7 +6187,7 @@
 	    break;
 
 	case OP_RETURN:
-	    if (o->op_next->op_type != OP_LEAVESUBLV) {
+	    if (o->op_next && o->op_next->op_type != OP_LEAVESUBLV) {
 		o->op_seq = PL_op_seqmax++;
 		break;
 	    }
End of Patch.

[p5pRT]

From @jandubois

On Fri, 12 Nov 1999 14​:47​:09 -0800, Gurusamy Sarathy
<gsar@​ActiveState.com> wrote​:

This looks like something I fixed a few weeks back.

Yes, it's exactly the same. I'm surprised I reduced the problem from
Win32​::OLE​::Const to almost exactly the same code you used in the
description of your patch. I cannot consciously remember "reading" your
patch before, but I just checked the xray archive and it was posted to
p5p. Fascinating! :-)

I just wasn't sure if simply checking o->op_next for NULLness was the
correct fix or if it would only cover the symptom.

-Jan