|
Re: Non-deterministic behaviour with simple array initialization
by Corion (Patriarch) on Sep 25, 2008 at 20:21 UTC
|
| [reply]
[d/l] |
|
|
I'm sorry about that, you're right. Thanks for the links.
Please note that on this post, it's perl 5.8.8. The full 'perl -V' is shown below.
| [reply]
[d/l] |
Re: Non-deterministic behaviour with simple array initialization
by mr_mischief (Monsignor) on Sep 25, 2008 at 20:56 UTC
|
If the problem follows the image, then it's likely some part of the image that's been corrupted. The guest OS's kernel or libc are suspect, as is the perl installation.
Try comparing the kernel, the perl executable, the C library, and libraries used by perl between the working image and non-working image a little deeper. In situations where file corruption is suspected du, cksum, md5sum, and diff are some tools to verify both sets of files are actually identical.
One way to speed this up is to create a tar file of the directories you suspect on each machine and compare the tar files. If the images are really identical then the tar files made from the same directories will be identical as well.
| [reply] |
|
|
I md5sum'ed and cksum'ed the kernel image and all files that are accessed according to strace. The /boot/initrd and /etc/ld.so.cache differ, but all other files are identical, including /usr/bin/perl and /lib64/libc.so.6.
In case that makes a difference: It's a 64-bit system.
Are there other files I should check?
| [reply] |
|
|
It's odd that ld.so.cache would be different on identical systems. That's supposed to be an ordered list of libraries found in the directories listed in ld.so.conf file. If you have additional libraries on one system not found on the other, that would explain that. Having additional libraries doesn't by itself explain the behavior at hand if they're libraries not actually used in the test, though.
The initrd file shouldn't be of any consequence after the system is booted and running, as it's used to provide a temporary root file system before the actual root is ready. Again, I'm not sure why identical images would have different versions of this file, but it shouldn't matter. The file could be different because the images were made separately on hardware with different capabilities. It is possible to leave things running from initrd running after the system is loaded, but I doubt Suse does that on a typical installation.
As for other files, I'm at a loss for the moment. I'll let you know if I think of anything, though.
| [reply] |
|
|
|
|
Re: Non-deterministic behaviour with simple array initialization
by Anonymous Monk on Sep 25, 2008 at 20:12 UTC
|
... which means that at some point suddenly @e is not undef anymore.
Not really :)
@x{1..2**31} = (); \%x
Range iterator outside integer range at - line 1.
On win32, activeperl5.8.6 and strawberryperl5.10, I get no error messages, the script just keeps running (i kill after 10min)
It has something to do with c compilers, int size, malloc ... probably deterministic, but thats range operator abuse :)
| [reply]
[d/l] |
|
|
Hi anonymous monk,
I don't get error messages on the other VM either, that's what makes this problem very strange to me ...
The range iterator message is one of the rare ones :) the illegal division or the sudden execution of the print statement after the n'th while loop is much more 'likely'.
Do you have a hint for me how I could narrow it further down? It's the default SuSE perl distribution, no custom stuff. Dop you think I should try to tackle it with valgrind or something?
Thanks,
Thomas
| [reply] |
Re: Non-deterministic behaviour with simple array initialization
by Jenda (Abbot) on Sep 25, 2008 at 21:02 UTC
|
Does moving the my @e; outside the outer loop make any difference?
Update: Yes, that's what I meant. I wanted to check whether it's in any way related to the repeated recreation of the @e variable. Looks like it isn't. Could you try to stick one more variable declaration right after the my $i = 0;? To add some padding between $i and @e.
| [reply]
[d/l]
[select] |
|
|
Hi Jenda,
you mean, right before the while(1)? No, same effect.
Update: I changed it like this:
my $i = 0;
my $pad = 'padding';
my $pad2 = 42;
my @e;
BIGLOOP: while (1) {
Is that what you meant? The problem is still there ...
| [reply]
[d/l] |
Re: Non-deterministic behaviour with simple array initialization
by BrowserUk (Patriarch) on Sep 25, 2008 at 21:47 UTC
|
| [reply]
[d/l] |
|
|
Hi,
thanks for the suggestion. I wrote a TestFor package, pretty straight according to the documentation, as seen below. The problem persists, and besides TIEARRAY and DESTROY once and many times FETCHSIZE, there is no method called on @e.
To clarify:
| [reply]
[d/l]
[select] |
|
|
The only other suggestion I have (which at least won't involve so much work!), is to see if you get the same problem if the array is a global: our @e.
Beyond that, it sounds like you just have a broken build. Rebuild it, or if its a vendor build grab an ealier one and report the problem to whomever built it.
Even if you tracked down what caused it, what would you do about it?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
|
|
Re: Non-deterministic behaviour with simple array initialization
by mr_mischief (Monsignor) on Sep 30, 2008 at 19:57 UTC
|
Has anything solved the issue? | [reply] |
|
|
Hi,
no, not really - but meanwhile I found out that it is not really a perl issue. I ran a valgrind on it, and I got a message like "the impossible happened". And I can reproduce the error on the Xen host itself.
Anyway, if I let the VM run alone on the Xen host, everything is fine and the error is gone. But as soon as a second VM is running in parallel on the same host, the error is there again. So I guess it's more a Xen issue, and I'll do a follow-up with the Xen guys as soon as I have enough evidence :)
Thanks for all your suggestions!
Thomas
| [reply] |