Jenda has asked for the wisdom of the Perl Monks concerning the following question:

I have a fairly strange issue here. I have ActivePerl v5.8.8 build 822 on MS Windows Server 2003 with IIS with both .pl and .plx assigned to ...\PerlIs.dll in two different websites. The PerlIs.dll is allowed in the Web Service Extensions and everything works fine in one of the websites. In the other as long as the script doesn't contain any "use" statement (apart from pragmas like strict and warnings) it works as well. As soon as there is a use statement, the script dies with "Script produced no output", there is nothing useful in the webserver log and "INTERNAL ERROR: PerlParse did not exit clean!!!!" in PerlIs-Err.log. If I put the use statement into eval"" I do not get even this.

use strict;
use warnings;
no warnings qw(uninitialized);
#use FileHandle;
#use IO::Tee;

print "HTTP/1.0 200 OK\r\nContent-type: text/html\r\n\r\n";
#print "Content-type: text/html\r\n\r\n";

eval "use IO::Tee;";
print "<html><body>Error=$@</body></html>\n";

[download]

If I change the script mapping to execute the scripts with perl.exe they work fine. And if I modify the module name to something that doesn't exist I do get the expected error message even from PerlIs.dll.

As the perl stuff is not used often I could leave it set up to perl.exe, but the (IMNSHO very annoying) fact that perl.exe and perlis.dll requires different headers (with or without the HTTP/1.0 status line) makes this a rather bad solution. Any ideas?

Update: I forgot to add that the two websites are set to use a different Application Pool, both contain a lot of plain old VBScript ASPs and the one where PerlIs.dll acts up uses some PerlCtrl produced DLLs from within those ASPs. I believe they were compiled with the same version of Perl (I've had problems with DLLs compiled with a different version than the one that was installed on the server and recompiled them. The symptoms were different.). I've tried to load all those DLLs into a Perl process on that server and load some modules ... no problem.</p

Thanks, Jenda
Support Denmark!
Defend the free world!

Replies are listed 'Best First'.
Re: eval "use Module::Name" silently dies under MS IIS/PerlIs.dll
by runrig (Abbot) on Nov 17, 2008 at 17:30 UTC
    I would think that the eval should be (otherwise I wouldn't expect any error):
    my $result = eval "use IO::Tee;";
die "Couldn't use IO::Tee: $@";

    [download]

    update: sorry I did not see the $@ in the line below your use statement until now

[reply]
[d/l]
[reply]
Re: eval "use Module::Name" silently dies under MS IIS/PerlIs.dll
by Herkum (Parson) on Nov 17, 2008 at 17:50 UTC

    I was going to ask, if you had check the versions of Perl and how they were compiled. Are you using Activestate for both or did you roll your own(Strawberry).

    It basically comes down to the .dll being the problem, the question is can you replace it with something that you know works.

[reply]

      ActivePerl v5.8.8 build 822 on both the server and the development machine where I generated the DLLs. Though it is possible that some module is in a different version. I had to recompile all the DLLs after I updated from 5.8.7 some time ago. With the new perl and old DLLs either the OLE objects failed to get created in the ASPs or the perl scripts refused to run. But they refused to run even if they contained just a single print statement.

      Besides I successfully loaded all those DLLs into a Perl script on that server and still was able to load additional modules.

      Jenda
      Support Denmark!
      Defend the free world!

[reply]

        Are dependent upon using that specific development machine? Can you get a vanilla server, as it were, and try your scripts on that? If you got your stuff to work on one box, but not another there has to be something wrong with the system in some way. It is a matter of finding out what though.

[reply]
Re: eval "use Module::Name" silently dies under MS IIS/PerlIs.dll
by ig (Vicar) on Nov 17, 2008 at 20:49 UTC

    Does the identity of the application pool on the failing site have permissions on the perl library directories and files? Maybe it is failing because it can't read the .pm files.

[reply]

      Ah, I did not notice the application pools have their own identities, I only checked the account set for the anonymous access to the website (website properties / Directory Security / Authentication and access control.

      In either case both websites and application pools use the same identities in both places. IUSR_... for the website and "Network Service" for the app pool :-(

      Jenda
      Support Denmark!
      Defend the free world!

[reply]

        You might write a script that does not use any modules but displays @INC, to make sure it is looking for modules where you think it is, and read a .pm file (open it directly, don't use it) to make sure there is no access problem on the file.

        In addition to the obvious settings in the IIS admin GUI, there may be differences in the metabase. You can review this as an XML file (assuming a reasonably recent version of IIS). It might be worth having a look there to see if anything differs between the sites.

[reply]
Re: eval "use Module::Name" silently dies under MS IIS/PerlIs.dll
by ig (Vicar) on Nov 18, 2008 at 20:39 UTC
    I could leave it set up to perl.exe, but the (IMNSHO very annoying) fact that perl.exe and perlis.dll requires different headers (with or without the HTTP/1.0 status line) makes this a rather bad solution.

    As of 5.10, Active State says they have solved this problem (See My CGI scripts don't seem to run right under PerlIS in http://docs.activestate.com/activeperl/5.10/faq/Windows/ActivePerl-Winfaq7.html), But perl.exe will still be slower than perlis.dll

    In the mean time, http://www.4images.com/ntperl/perlis.htm recommends starting your scripts with:

    if($ENV{'PerlXS'} eq 'PerlIS')
print "HTTP/1.0 200 OK\n";

    [download]

    But check documentation for 5.8.8 for the environment variable name. Documentation for 5.10 says it is PERLXS, not PerlXS.

[reply]
[d/l]
      perl
$ENV{fuzzy}="case dont matter";
die $ENV{FuZzY};
__END__
case dont matter at - line 2.

      [download]
[reply]
[d/l]

Back to Seekers of Perl Wisdom