More on "IO object version does not match bootstrap parameter" error

[jkeenan1]

Several days ago, I posted an inquiry (Diagnosing error report: "IO object version 1.21 does not match bootstrap parameter 1.22") concerning certain FAIL reports I was getting at testers.cpan.org (http://tinyurl.com/c8xd5) on uploads of a module I am maintaining. For reasons not clear to me, some (but not all) testers would report massive test failures, all of them starting out something like this:

IO object version 1.21 does not match bootstrap parameter 1.22 at /usr
+/local/perl-5.8.5/lib/5.8.5/sun4-solaris-thread-multi/DynaLoader.pm l
+ine 253.

I noted that I could not reproduce this error and was puzzled because I didn't call IO::Handle in any of my code, nor did I make any use of Dynaloader. (There's no XS in the distro.)

chromatic commented that "that error means that the version in the XS portion of IO does not match the version in the Perl portion of the module. It sounds like an incorrect installation of Perl."

Since that time there have been further developments. First, there have been more confusing automated testing reports. One of the testers who first reported the "IO object version" errors has re-tested ExtUtils-ModuleMaker-0.39 and it is now passing (http://tinyurl.com/awhay). But another tester first reported the distro as passing all tests, then switched to two different architectures (though all Linux) and reported failures -- with the same type of errors -- on those later architectures! (Go to http://tinyurl.com/c8xd5 and look at reports 241985, 242337 and 242426.)

Second, I googled for this error (http://tinyurl.com/7v7dc) and scanned the results. I got 44 hits (including duplicates) going back to 1999 from lists such as comp.lang.perl.misc, debian-user, perl.par, etc. Sometimes the error looks like this:

IO object version 1.20 does not match bootstrap parameter 1.21 at
C:/Perl/lib/XSLoader.pm line 91.
Compilation failed in require at C:/Perl/lib/IO/Handle.pm line 260.
BEGIN failed--compilation aborted at C:/Perl/lib/IO/Handle.pm line 260
+.
Compilation failed in require at C:/Perl/lib/IO/Seekable.pm line 101.
BEGIN failed--compilation aborted at C:/Perl/lib/IO/Seekable.pm line 1
+01.
Compilation failed in require at C:/Perl/lib/IO/File.pm line 117.
BEGIN failed--compilation aborted at C:/Perl/lib/IO/File.pm line 117.
Compilation failed in require at -e line 300.

Sometimes like this:

debconf: Perl may be unconfigured (IO object version
1.20 does not match bootstrap parameter 1.18 at
/usr/lib/perl/5.6.1/DynaLoader.pm line 221.

Sometimes like this:

debconf: Perl may be unconfigured (IO object version
1.20 does not match bootstrap parameter 1.18 at
/usr/lib/perl/5.6.1/DynaLoader.pm line 221.

What's interesting in reviewing these postings is that -- unlike most postings to Perl lists -- the OP's question never gets a definitive answer. Often the answer falls along the lines of "reinstall Perl."

The most thorough answer that I found was (not surprisingly) from Sherm Pendley (http://www.dbforums.com/t1064830.html). Sherm wrote:

So you have the latest IO.pm, which is reporting version 1.21, but when DynaLoader tries to load IO.so, that reports version 1.18. This is a fatal problem, so DynaLoader complains about it and dies.

Perl has separate directories for version-specific modules specifically to prevent this sort of problem. The fact that it's happening usually indicates either a module install gone very wrong, or a very badly misconfigured perl.

The first problem listed is the one you need to diagnose and fix first - the others are a result of the first. When IO fails to load, the module that tried to use it (IO::Handle) fails. Then the module that tried to use IO::Handle fails. And so on, until the main script fails at the end.

So the key to solving the problem is figuring out *why* your Perl is loading the latest IO.pm, but an older IO.so.

The thread trailed off there; I don't know if the poster Sherm was helping ever diagnosed the problem further or solved it. But if more than one CPAN tester -- each of whom, I presume, is a highly experienced Perl hacker -- is generating spurious error reports based on this error, then the problem has to be judged a serious one and worthy of serious attention by the community.

Since problems with IO modules, .so objects and perl distributions are beyond my personal expertise, I'm wondering where I should report the problem for further investigation. Suggestions?

Thank you very much.

Jim Keenan

[dave_the_m]

Right, lets go back to basics. Some perl modules, including some core ones, contain a mixture of both C and Perl. The perl code usually resides in the file Foo.pm, while the C code resides in Foo.xs. When the module is installed (or for a core module, when perl is built), the .xs file is compiled into a Foo.so library file. Foo.pm will usually have a line in it like $Foo::VERSION = 1.21. Similary, that version number will compiled into the .so object.

At runtime, when code does 'use Foo;', Foo.pm is loaded and executed; Foo.pm will then call Dynaloader.pm to do the clever stuff related to linking the Foo.so object into the perl runtime. At this point, Dynaloader checks whether $Foo::VERSION matches the version in the .so file, and if not dies with the error you're seeing.

Some further pertinant facts: the version of IO bundled with all recent perls (5.8.1-5.8.7, 5.9.0-5.9.2) is 1.21; however, there is a newer version available on CPAN, 1.22.

I would conclude therefore, that on some of your testers' machines, they have somehow (perhaps automatically) downloaded IO-1.22 from CPAN and partially or fully installed it somewhere on their system; that your test code or something that calls your test code, is directly or indirectly useing or requiring IO; and that the various library search paths and environment variables at this point are such that the built-in IO.pm 1.21 but also the external IO.so 1.22 are being found. Possibly (but not necessarily) related to how your module sets up or modifies such paths.

Dave.

[jkeenan1]

Thanks, Dave, for the cogent explanation. That would explain why some testers are reporting the errors and others are not. Of course, that in turn raises the question: How can we encourage our testers to correct such problems?

As to what in my code is triggering the problem, the most likely candidate is File::Temp, which is used in all files in test suite except the first -- which is the one file that gets through all its tests. But the problem is probably not File::Temp per se but the IO::Handle which File::Temp calls internally.

I'm loathe to stop using a core module such as File::Temp in my test suite, particularly because part of the testing process is the creation of files and directories which ought to be done in a protected environment such as File::Temp provides. And what about folks who use File::Temp in their module code, not just in their test suites?

Thanks again for taking the time to think about this problem.

Jim Keenan

[randyk]

It's probably a problem beyond your control; for example, for the particular failure of ExtUtils-ModuleMaker-0.39, within the same run for this particular testing machine, the same failure was reported for

• Imager-0.45
• Text-Record-Deduper-0.05
• Genezzo-0.50
• IO-NestedCapture-1.02
• HTTP-OAI-3.10
• Pod-POM-View-SPIP-0.03
Earlier on in this run IO-1.22 was tested, and passed, probably as a result of some other package requiring it. What probably happens is that the build directory for this IO-1.22 gets added to @INC in a way so as to cause this version mis-match within the testers machine.

Thus, it seems that this failure depends on some other package happening to have a prerequisite of IO that is tested before your package is tested. You can't do very much about that, beyond reporting the problem to the authors of the automated testing software.

[jkeenan1]

CPAN tester imacat re-tested ExtUtils::ModuleMaker (repeatedly! and on multiple OSes! valiant work) and sent me this message:

I tested it again and could not reproduce the same failure. However I found that error is caused by the incompatibility from the just-tested IO 1.22 with Perl itself boundled with IO 1.21. Due to some test suite problem it keeps loading the just-tested IO 1.22 from @INC and caused incompatibility problem with Perl itself. I have submit several OK reports on ExtUtils-ModuleMaker, and forwarded this message to Robert Rothenberg, the author of CPAN::YACSmoke.

Jim Keenan

[[e-mail]]

Jim, I tried to reply to your email on this subject that you sent to me as a result of the cpan test, however replies to you bounced because of an over-zealous anti-spam checker at your ISP. Here is the main point of the email I sent you: I will look into it, but please be aware that the testing environments are all, deliberately, as standard as possible. Therefore any anomalies on them may well exist on other users' systems, perhaps because of packagers/maintainers issues. -Nigel

[jkeenan1]

Thanks, Nigel. That's the first time anyone has accused the spam-checker at verizon.net of being over-zealous! I will send you e-mail and we'll see if we can communicate.

And, yes, I realize that this is larger than an individual tester's setup. So it becomes a community problem and not just a technical problem.

Thanks for your testing efforts.

Jim Keenan

[gedge]

I just hit this (with IO, too) - sigh! - so am leaving this one-liner here, for future me:

for i in $(perl -E 'say for @INC'); do find $i -type d -perm 700 -exec
+ chmod 755 {} \;;done

[sfink]

This suggests that a useful mechanism would be to have "pre-tests" that check out the environment. If a pre-test failed, then the main test results (positive or negative) would not be reported, and the tester would be informed of the problem.

And then, to go with this, we'd want a standard Test::Sanity or Test::Configuration or Test::NotMyFault that people could submit their checks too, so it could gradually accrete tests for the most common misconfigurations that CPAN authors have been unfairly blamed for.

Finally, we'd need... well... someone to actually implement those two suggestions. (/me hides)

[Anonymous Monk]

I found a strange source of similar errors which may not apply in this case, but did drive me crazy for a week. The Encode module, rather than hard-coding VERSION, uses CVS tags for Revision with code to translate that tag into standard numbers. It is nice for developers, I am sure. Unfortunately, I checked some pm files from Encode into my CVS along with other code. The end result being that my CVS changed the revision tag, and thus the apparent version. When the version did not match the .so file, it broke. The only reason I discovered this was that I recompiled, checked the new pm files into CVS and the revision number in the error changed. Now, I am not sure how many other people check third party perl files into their CVS, but this is definitely one possible cause. And since I stumbled across this page while trying to figure out that very problem, I figured I should mention it in case someone else is having the same problem.

[Anonymous Monk]

I just struugled through this problem. I fixed it by noticing that some modules I installed via sudo /usr/bin/cpan were installed with a umask 027, meaning that I, as "other", saw an inconsistent view of my Perl library space. When I fixed the permissions, the problem went away.

To address why perl loads the latest IO.pm but an older IO.so, assume the latest IO.so is mode r-xr-x--- (550). Perl will try to load the first readable IO.so it can find, which won't match the latest IO.pm

[Preceptor]

A bit of an old thread, but it solved my problem so I shall comment. Some of my mods were installed without global Read/Write, and so version mismatches were occurring when running as e.g. root vs. not root.

chmod -R a+rX /usr/local/lib/perl5/site_perl/5.18.1

Resolved the problem.