http://qs1969.pair.com?node_id=617066

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

Greetings brethren. It's been too long since I've been enveloped in the warmth of perl on a daily basis, as I've been doing too much Project Management, and not enough coding.

But I now find myself facing an unsavory problem. We have an application which may have multiple unrelated instances running on a machine. On Windows, these applications sometimes (.001% of the time) will die with: 

Can't load 'c:/xgsPerl/5.8.5/lib/auto/File/Glob/Glob.dll' for module F
+ile::Glob: load_file:%1 is not a valid Win32 application at c:/xgsPer
+l/5.8.5/lib/XSLoader.pm line 68.

[download]

(this is perl 5.8.5)

This problem never happens with only one instance of the tool running, leading us to suspect concurrency issues (duh)

Assume for a minute we are in a frozen development environment, and updating the version of perl or File::Glob is not an option.

A couple of questions

Thanks,
~Jeff

Replies are listed 'Best First'.
Re: Problems sometimes loading File::Glob
by jettero (Monsignor) on May 23, 2007 at 18:13 UTC

    ... isn't glob and even just @files = <*.*> a builtin? Is that wrong? Oh! It says right on the page I linked that glob is the angles and that they are File::Glob. I was not aware of that.

    Do you have more than one perl installed? Personally, I'd reinstall perl if I discovered a corrupted core dll like that. To hells with feature freezes or whatever. That'd be a serious stability issue.

    UPDATE: based on shmem's musings... If you pop open that dll, does it have win32 headers in there? Is it in fact corrupted in some way?

    -Paul

[reply]
[d/l]
      Yes, it is a builtin, but: 
      10] perldoc -f glob
       glob EXPR
       glob    In list context, returns a (possibly empty) 
               list of filename expansions on the value of 
               EXPR such as the standard Unix shell /bin/csh 
               would do. In scalar context, glob iterates 
               through such filename expansions,
               returning undef when the list is exhausted. 
               This is the internal function implementing 
               the "<*.c>" operator, but you can use it directly. 
               If EXPR is omitted, $_ is used.  The "<*.c>" 
               operator is discussed in more
               detail in "I/O Operators" in perlop.

               Beginning with v5.6.0, this operator is 
               implemented using the standard "File::Glob" 
               extension.  See File::Glob for details.

      [download]
      So the builtin glob calls load the File::Glob module on the fly apparently
[reply]
[d/l]
      One perl installed. There is nothing wrong with the .dll itself. I've compared checksums of the .dll on 20 different machines, and they all match. And keep in mind, this loads and works fine 99.99% of the time.

      I've learned something new here, putting an eval block around the glob does nothing. Apparently the compiler sees the glob at compile time, and goes off to load the File::Glob module at that time.

      So now I'm faced with a different issue that I may form as another SoPW Thanks,
      ~Jeff

[reply]
[d/l]
[select]
Re: Problems sometimes loading File::Glob
by shmem (Chancellor) on May 23, 2007 at 18:16 UTC
    This problem never happens with only one instance of the tool running, leading us to suspect concurrency issues (duh)

    From your description I suspect the same, but I might be wrong. DLLs should be shared objects, shouldn't they? What's around line 68 of XSLoader?

    Is Windows setting a lock on the DLL while opening it, then releasing the lock? That would be an explanation, but really bad behaviour also.

    eval seems the way to go, but not around the glob() calls - it should go around the use File::Glob call in a loop, retrying after a small amount of time and aborting after $count tries, since the DLL is bootstrapped upon loading the module AFAIK.

    sm<update>

    After seeing your post above, I'd sugges to try the BEGIN block trick to not defer the loading of File::Glob to the compiler.

    </update>

    --shmem 

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
[reply]
[d/l]
[select]
      But we don't 'use File::Glob'. It gets loaded dynamically via the call to glob().

[reply]
[d/l]
        Ah then, of course, yes, around the first glob() call.
[reply]

Back to Seekers of Perl Wisdom