in reply to Re^2: Error Message "Can't load 'C:/Perl64/lib/auto/DBD/Oracle/Oracle.dll" While Connecting to Oracle (not valid)
in thread Error Message "Can't load 'C:/Perl64/lib/auto/DBD/Oracle/Oracle.dll" While Connecting to Oracle

Reading the linked thread, I didn't see a clear cause clearly called out, but it looked to me like the problem in that case was that the DLL's base address conflicted with some other DLL's base address.

Other likely types of "corruption" could be mixing 64-bit and 32-bit components. Yes, I realize that "corruption" isn't the correct term for any of this. ;)

One next step I might do is watch what the perl process is doing when this fails. Is there a sysinternals-like process monitor that works on Windows 7 these days? Even a file system monitor might help in pointing at which library is the real problem.

On Unix, I'd ask lsof to tell me what other DLLs are loaded so I could just check for conflicting base addresses (seems a poor system to be vulnerable to such -- but maybe I misunderstood the real root cause in that other thread). I'm not sure how to do the equivalent on Windows, but that shouldn't be hard to look up.

(Updated: To move the last sentence of the 2nd-to-last paragraph to be the last sentence of the last paragraph, as I had originally intended.)

- tye        

  • Comment on Re^3: Error Message "Can't load 'C:/Perl64/lib/auto/DBD/Oracle/Oracle.dll" While Connecting to Oracle (not valid)

Replies are listed 'Best First'.
Re^4: Error Message "Can't load 'C:/Perl64/lib/auto/DBD/Oracle/Oracle.dll" While Connecting to Oracle (not valid)
by bulk88 (Priest) on Jan 27, 2014 at 05:00 UTC
    Reading the linked thread, I didn't see a clear cause clearly called out, but it looked to me like the problem in that case was that the DLL's base address conflicted with some other DLL's base address.

    base address conflicts only happen on cygwin due to how they implement their fork. Cygwin might have been fixed by now. Very old Win32 GCC (2.x/3.x) also couldn't generate relocation information, or created garbage entries, and the garbage entries only were a problem if the Win32 DLL loader tried to relocate.

    One next step I might do is watch what the perl process is doing when this fails. Is there a sysinternals-like process monitor that works on Windows 7 these days? Even a file system monitor might help in pointing at which library is the real problem. I'm not sure how to do the equivalent on Windows, but that shouldn't be hard to look up.

    Dependency Walker is what you want. Use the profiling feature in DW. Procmon will also work, but its output is extremely noisy when all you want DLL info, not every file, thread life, and reg access. Manipulating the filters in procmon is alot of work when you could just use dep walker instead.

    On Unix, I'd ask lsof to tell me what other DLLs are loaded so I could just check for conflicting base addresses (seems a poor system to be vulnerable to such -- but maybe I misunderstood the real root cause in that other thread).

    Doesn't Unix always make PIC ELFs that dont need relocation? and ELF has relocation if you really want it anyway in the standard.
[reply]

      Thanks!

      - tye        

[reply]

In Section Seekers of Perl Wisdom