Problems sometimes loading File::Glob

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

Does anyone have a good explanation for what we are seeing?
Any suggestions for working around it? (my current idea is to eval{} the glob() calls)
Does anyone have a pure perl glob() implementation we could drop in and try?

Thanks,
~Jeff

Comment on Problems sometimes loading File::Glob Download Code

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]
Re^2: Problems sometimes loading File::Glob by HuckinFappy (Pilgrim) on May 23, 2007 at 18:18 UTC
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]
Re^2: Problems sometimes loading File::Glob by HuckinFappy (Pilgrim) on May 24, 2007 at 14:25 UTC
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]
Re^2: Problems sometimes loading File::Glob by HuckinFappy (Pilgrim) on May 23, 2007 at 18:20 UTC
But we don't `'use File::Glob'`. It gets loaded dynamically via the call to glob().	[reply] [d/l]
Re^3: Problems sometimes loading File::Glob by shmem (Chancellor) on May 23, 2007 at 18:37 UTC
Ah then, of course, yes, around the first glob() call.	[reply]
Re^4: Problems sometimes loading File::Glob by HuckinFappy (Pilgrim) on May 24, 2007 at 22:57 UTC


Keep It Simple, Stupid
	PerlMonks