if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location

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

$ pmvers XML::LibXML Digest::SHA1
XML::LibXML: 2.0012
Digest::SHA1: 2.13

$ pmvers Digest::SHA1 XML::LibXML
Digest::SHA1: 2.13
C:\perl\site\5.14.1\bin/pmvers: Can't load 'c:/perl/site/5.14.1/lib/MS
+Win32-x86-multi-thread/auto/XML/LibXML/LibXML.dll'
 for module XML::LibXML: load_file:Invalid access to memory location a
+t c:/perl/5.14.1/lib/MSWin32-x86-multi-thread/Dyna
Loader.pm line 190.
 at c:/perl/site/5.14.1/lib/MSWin32-x86-multi-thread/XML/LibXML.pm lin
+e 154.
BEGIN failed--compilation aborted at c:/perl/site/5.14.1/lib/MSWin32-x
+86-multi-thread/XML/LibXML.pm line 154.
Compilation failed in require
[download]

Can you replicate? Other ideas?

Comment on if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location Download Code

Replies are listed 'Best First'.
Re: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by syphilis (Archbishop) on Nov 14, 2012 at 09:17 UTC
I know I've struck the same problem, where the order in which the modules were loaded determined whether I got that error or not. And I know the modules with which I had this trouble were not the 2 that you have specified ... but I can't remember precisely which modules it was for me. I also know that I didn't ever come to an understanding of exactly what was going wrong ... but I know I found a way to make the problem vanish, and I think (not entirely sure) that the problem vanished once I made sure that it was the same (MinGW port of gcc) compiler that had built perl && the 2 problematic modules && all third party libraries upon which the modules relied. So maybe try that (if applicable). At least, if you think it might be worth the effort, make sure that Digest::SHA1, XML::LibXML, and your XML library are all built by the same compiler - even if that's not the compiler that actually built perl. What's your `perl -V` ? Cheers, Rob	[reply] [d/l]
Re^2: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by Anonymous Monk on Nov 14, 2012 at 10:03 UTC
... and I think (not entirely sure) that the problem vanished once I made sure that it was the same (MinGW port of gcc) compiler that had built perl && the 2 problematic modules && all third party libraries upon which the modules relied. thank you, I had a vague notion of deja vu but I just couldn't remember the details -- there is a high probability this is the exact issue	[reply]
Re: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by Athanasius (Archbishop) on Nov 14, 2012 at 09:14 UTC
Can you replicate? No (Windows Vista 32-bit): `18:58 >perl -v This is perl 5, version 14, subversion 2 (v5.14.2) built for MSWin32-x +86-multi-thread ... 18:58 >pmvers XML::LibXML Digest::SHA1 XML::LibXML: 2.0012 Digest::SHA1: 2.13 18:59 >pmvers Digest::SHA1 XML::LibXML Digest::SHA1: 2.13 XML::LibXML: 2.0012 18:59 >` [download] Other ideas? Well, here’s the comment in the code immediately before line 190 of DynaLoader.pm: `# Many dynamic extension loading problems will appear to come from # this section of code: XYZ failed at line 123 of DynaLoader.pm. # Often these errors are actually occurring in the initialisation # C code of the extension XS file. Perl reports the error as being # in this perl code simply because this was the last perl code # it executed.` [download] So — maybe the XML::LibXML build was faulty? Have you examined the build log? Tried reinstalling? Athanasius <°(((>< contra mundum	[reply] [d/l] [select]
Re: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by tobyink (Canon) on Nov 14, 2012 at 10:02 UTC
I don't have an answer to your specific question, but consider using Digest::SHA instead of Digest::SHA1. Digest::SHA has been bundled with Perl since 5.10. `perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'`	[reply]
Re^2: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by Anonymous Monk on Nov 14, 2012 at 10:05 UTC
FWIW, the issue arose in the XML::Compile::WSS test-suite, I'm not actually using Digest anything :)	[reply]
Re: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by bulk88 (Priest) on Dec 03, 2012 at 02:32 UTC
"load_file:Invalid access to memory location" means one and only one thing, in the XS DLL, or any dependency DLL which has not been loaded before (kernel32, advapi32, perl51*.dll for example were already loaded so they can not be the cause), a DllMain of the new in the process DLL, had a SEGV/access violation, when it was called from LoadLibrary/Dynaloader. Windows instead of crashing the process, traps the access vio and returns FALSE to the caller (Dynaloader) of LoadLibrary and sets Win32 LastError correct and that is what you see here. Try http://www.dependencywalker.com/, IDK if it will help you identify which particular DLL crashed or not the tree of dependencies. The other choice is a C debugger which will ideally answer the problem in a few seconds. Win32 specific XS modules rarely define a DllMain, and portable XS modules never will, but all DLLs have a DllMain placed by the C compiler, usually to initialize various clib/crt features or hook OS thread creation for TLS reasons.	[reply]
Re^2: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by Anonymous Monk on Dec 03, 2012 at 09:54 UTC
You don't say :/ that isn't exactly new to me :) dependencywalker won't try to load two dlls at once, so I can't trigger this error using that tool Usually, I'll get a drwtsn32 popup, which'll tell me which dll the memory access violation happened upon (not just the perl/xs dll) I have WinDbg , but there is nothing extra there if I attach (F6) to `perl.exe -e " require Digest::SHA1; scalar <>; require XML::LibXML; "` and Go (F5) or "Go Handled Exception" from Debug menu `ModLoad: 00ca0000 00f84000 ....auto\XML\LibXML\LibXML.dll (8e8.aec): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=0022ed8c ebx=00ca1420 ecx=00009599 edx=00000001 esi=0022ed14 edi=0 +0000001 eip=00ca1427 esp=0022ece8 ebp=0022ed20 iopl=0 nv up ei pl nz a +c pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=0 +0010216` [download] I recognize c0000005 but I don't see a faulting module and fault addressss I get this on two different perl versions (v5.14.1 , v5.16.1 ) , with two different gcc `gcc version 4.6.3 (gcc-4.6.3 release with patches [build 20121012 by p +erlmingw.sf.net]) gcc version 4.7.0 (GCC) (mingw.org)` [download] Any other ideas I can try?	[reply] [d/l] [select]
Re^3: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by bulk88 (Priest) on Dec 03, 2012 at 15:55 UTC
Dependency walker can "profile" a process, menubar->profile->start profiling, it will log every DLL static and dynamic linked during the whole run life of the process. Since I assume you are using Mingw, you need to compile the XS module without "-s" so it has debugging info then use the gdb infrastructure so you have symbols and can see the original C code and original var names. I can't give any specifics to WinDbg since its UI is much more difficult than VS Debugger. You probably have to goto disassembly window in WinDbg, see the current instruction address, or use register EIP in the dump above. Then figure out which mapped into address space DLL that EIP falls into. You can use http://virtualmemorymapview.codeplex.com/releases/view/28113 or MS's VMMap to see where the DLLs are in that processes memory.	[reply]
Re^4: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by Anonymous Monk on Dec 03, 2012 at 17:52 UTC
Re^5: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by Anonymous Monk on Dec 04, 2012 at 00:17 UTC
Some notes below your chosen depth have not been shown here
Re: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by Anonymous Monk on Dec 02, 2012 at 17:12 UTC
grr, had an old libstdc++-6.dll hanging around	[reply]
Re^2: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by Anonymous Monk on Dec 02, 2012 at 17:16 UTC
and that helps some other similar things, but not this particular issue	[reply]
Re: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by Anonymous Monk on Dec 03, 2012 at 11:31 UTC
Ok, a development, through (:irksome:) manual hacking of Makefile perl -pi.orig -e " s{libxml2.a }{libxml2.dll.a }gis " Makefile I now link against libxml2-2.dll and this particular error doesn't happen, although I would still like to figure it out	[reply]
Re^2: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by syphilis (Archbishop) on Dec 04, 2012 at 05:21 UTC
perl -pi.orig -e " s{libxml2.a }{libxml2.dll.a }gis " Makefile Is libxml2.a a static lib ? ... or is it another import lib for a dll ? When I try to build XML-LibXML-2.0012 against a static libxml2.a, the build fails because it expects dynamic libxml2 symbols (prefixed with '_imp__'). Either your libxml2.a is not a static lib, or you've included a hack that tells the build we're linking to a static library. (What is that hack, btw ?) Cheers, Rob	[reply]
Re^3: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by Anonymous Monk on Dec 05, 2012 at 05:32 UTC
When I try to build XML-LibXML-2.0012 against a static libxml2.a, the build fails because it expects dynamic libxml2 symbols (prefixed with '_imp__'). If you're getting that _imp stuff you're building against the DLL -- you need `perl Makefile.PL DEFINE=" -DLIBXSLT_STATIC -DLIBEXSLT_STATIC -DLIBXML_STATIC " ...` to build sucessfully against static version, in addition to the appropriate LIBS/INC The problem with Makefile.PL is it rewrites my LIBS/INC arguments to what it thinks should be -- doesn't let me choose between static/dynamic -- kind of defeats the purpose of those args Hmm, I guess I could have installed the static/dynamic versions in different directories -- then when Makefile.PL does its detecting it can't choose wrong -- I guess `sh configure --disable-static --enable-shared prefix=/junk/static make install sh configure --disable-shared --enable-static prefix=/junk/dynamic make install` [download]	[reply] [d/l] [select]
Re^4: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by syphilis (Archbishop) on Dec 05, 2012 at 09:33 UTC
Re^5: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by Anonymous Monk on Dec 05, 2012 at 09:46 UTC
Re: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by Anonymous Monk on Dec 05, 2012 at 14:57 UTC
For any mingw-w64 folk that might stop by, I used citrusperl-standard-51601-msw-x86-017.zip, download, unzip, run citrusreloc.exe, run citrusutils.exe and "set gcc" to download gcc that built that perl ( IIRC it is gcc/i686-w64-mingw32/4.6.3 Also installed the accompanying standard-msys-20111122.7z and built libxml2-2.9.0 Perl module is http://search.cpan.org/dist/XML-LibXML-2.0012	[reply]
Re^2: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by syphilis (Archbishop) on Dec 06, 2012 at 05:24 UTC
I used citrusperl-standard-51601-msw-x86-017.zip If you're using citrus, then Mark Dootson (citrus developer, I believe) would probably be keen to know about this problem you've struck. I don't think he frequents the monastery - so you're best to attract his attention by other means. I can probably give you a contact for him if you don't already have one. Cheers, Rob	[reply]
Re^3: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location by Anonymous Monk on Dec 06, 2012 at 13:47 UTC
:) Thanks but it appears I've figured it out the problem, it is ImageBase collision It is fixed with a rebase rebase when the default -Wl,--enable-auto-image-base generates a collision, you can also rebase with `perl -pi.orig -e " s{^(LDDLFLAGS = )}{$1 -Wl,--image-base=0x70000000 }; " Makefile` FWIW, StrawberryPerl uses same compiler	[reply] [d/l]

Back to Seekers of Perl Wisdom