[perl #17091] 64-bit-int builds broken
Andy Dougherty
# Please include the string: [perl #17091]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17091 >
Not OK: This is a failure report for parrot.
64-bit-int builds appear to be broken. This is from Linux/SPARC with
INTVAL='long long'. This configuration used to work quite recently.
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/op/basic.t 14 3584 15 14 93.33% 2-15
t/op/bitwise.t 20 5120 20 20 100.00% 1-20
t/op/debuginfo.t 4 1024 4 4 100.00% 1-4
t/op/gc.t 5 1280 5 5 100.00% 1-5
t/op/globals.t 1 256 1 1 100.00% 1
t/op/hacks.t 1 256 1 1 100.00% 1
t/op/ifunless.t 6 1536 6 6 100.00% 1-6
t/op/info.t 1 256 1 1 100.00% 1
t/op/integer.t 39 9984 39 39 100.00% 1-39
t/op/interp.t 1 256 1 1 100.00% 1
t/op/lexicals.t 2 512 2 2 100.00% 1-2
t/op/macro.t 12 3072 13 12 92.31% 1-4 6-13
t/op/number.t 33 8448 33 33 100.00% 1-33
t/op/rx.t 22 5632 23 22 95.65% 1-22
t/op/stacks.t 34 8704 35 34 97.14% 1-27 29-35
t/op/string.t 95 24320 95 95 100.00% 1-95
t/op/time.t 4 1024 4 4 100.00% 1-4
t/op/trans.t 18 4608 18 18 100.00% 1-18
t/pmc/array.t 5 1280 5 5 100.00% 1-5
t/pmc/boolean.t 6 1536 6 6 100.00% 1-6
t/pmc/intlist.t 2 512 2 2 100.00% 1-2
t/pmc/perlarray.t 15 3840 15 15 100.00% 1-15
t/pmc/perlhash.t 15 3840 15 15 100.00% 1-15
t/pmc/perlstring.t 7 1792 8 7 87.50% 1-4 6-8
t/pmc/pmc.t 67 17152 68 67 98.53% 1-32 34-68
t/pmc/sub.t 3 768 3 3 100.00% 1-3
t/src/intlist.t 4 1024 4 4 100.00% 1-4
5 subtests skipped.
Failed 27/28 test scripts, 3.57% okay. 436/444 subtests failed, 1.80% okay.
Something very basic has gone wrong. Here's the gdb output from
t/op/basic_1.pbc:
(gdb) run t/op/basic_1.pbc
Starting program: /home2/doughera/parrot/parrot-andy/parrot
t/op/basic_1.pbc
Program received signal SIGSEGV, Segmentation fault.
0x0001144c in do_panic (interpreter=0x0, message=0xfda88 "Null vtable
used",
file=0xfdaa0 "pmc.c", line=46) at exceptions.c:37
37 printf("Parrot VM: PANIC: %s!\n\
(gdb) where
#0 0x0001144c in do_panic (interpreter=0x0,
message=0xfda88 "Null vtable used", file=0xfdaa0 "pmc.c", line=46)
at exceptions.c:37
#1 0x00077fec in pmc_new (interpreter=0x0, base_type=10) at pmc.c:46
#2 0x00011534 in init_world () at global_setup.c:33
#3 0x0007dc94 in Parrot_new () at embed.c:30
#4 0x000e9008 in main (argc=2, argv=0xeffffa54) at test_main.c:33
Summary of my parrot 0.0.8 configuration:
configdate='Mon Sep 9 15:20:06 2002'
Platform:
osname=linux, archname=sparc64-linux-64int
jitcapable=0, jitarchname=nojit,
jitosname=nojit, jitcpuarch=i386
perl=/home2/doughera/perl-gcc/bin/perl
Compiler:
cc='cc', ccflags='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g',
Linker and Libraries:
ld='cc', ldflags=' -L/usr/local/lib -L/opt/gnu/lib ',
cc_ldflags='',
libs='-lnsl -ldl -lm -lcrypt -lutil'
Dynamic Linking:
so='.so', ld_shared='-shared',
ld_shared_flags=''
Types:
iv=long long, intvalsize=8, intsize=4, opcode_t=long long, opcode_t_size=8,
ptrsize=4, ptr_alignment=4 byteorder=87654321,
nv=double, numvalsize=8, doublesize=8
--
Andy Dougherty doug...@lafayette.edu
Dept. of Physics
Lafayette College, Easton PA 18042
Andy Dougherty
> 64-bit-int builds appear to be broken. This is from Linux/SPARC with
> INTVAL='long long'. This configuration used to work quite recently.
I've at least figured out why it core dumps -- do_panic() assumes we've
got a valid interpreter, and tries to print out interpreter->line and
interpreter->flags. That's obviously not going to work if the problem is
(as it is here) that interpreter=0x0. I think the giant print statement
needs to be broken up into pieces which are conditional on the appropriate
things being passed in.
Andy Dougherty doug...@lafayette.edu
Andy Dougherty
> 64-bit-int builds appear to be broken. This is from Linux/SPARC with
> INTVAL='long long'. This configuration used to work quite recently.
The immediate culprit was config/gen/core_pmcs.pl, which now puts out
prototypes of
extern void Parrot_xxx_class_init(int);
while classes/pmc2c.pl is using
extern void Parrot_xxx_class_init(INTVAL);
This won't necessarily work if sizeof(INTVAL) != sizeof(INT). (And since
the prototypes are hidden in the C file, not in a shared header file, the
compiler doesn't warn about them.) Upon reflection, however, since the
number is used as an entry to look up in an array, I think 'int' is indeed
the appropriate type, so I've changed classes/pmc2c.pl to match.
This should reclaim the 64-bit tinderboxes, unless someone else has gone
and broken them again in a different way :-(.
--- parrot-orig/classes/pmc2c.pl Thu Sep 5 14:23:01 2002
+++ parrot-andy/classes/pmc2c.pl Tue Sep 10 11:54:51 2002
@@ -310,11 +310,11 @@
my $initline = 1+count_newlines($OUT)+1;
$OUT .= qq(#line $initline "$cfile"\n) unless $suppress_lines;
$HOUT .= <<EOH;
-void $initname (INTVAL);
+void $initname (int);
EOH
$OUT .= <<EOC;
-void $initname (INTVAL entry) {
+void $initname (int entry) {
struct _vtable temp_base_vtable = {
NULL,
--
Andy Dougherty doug...@lafayette.edu
Andy Dougherty
This patch breaks up the giant print statement into manageable pieces,
and included paranoid checking before dereferencing pointers.
--- parrot-orig/exceptions.c Wed Mar 6 10:45:28 2002
+++ parrot-andy/exceptions.c Tue Sep 10 11:55:04 2002
@@ -34,33 +34,29 @@
do_panic(struct Parrot_Interp *interpreter, const char *message,
const char *file, int line)
{
- printf("Parrot VM: PANIC: %s!\n\
-C file %s, line %d\n\
-Parrot file %s, line %d\n\
-\n\
+ printf("Parrot VM: PANIC: %s!\n", message ? message : "(no message available)");
+ printf("C file %s, line %d\n", file ? file : "(file name not available)", line);
+ printf("Parrot file %s, ", "(not available)");
+ if (interpreter)
+ printf("line %d\n", interpreter->current_line);
+ else
+ printf("line ((not available)\n");
+ printf("\n\
We highly suggest you notify the Parrot team if you have not been working on \n\
Parrot. Use bugs6.perl.org or send an e-mail to perl6-i...@perl.org. \n\
Include the entire text of this error message and the text of the script that \n\
generated the error. If you've made any modifications to Parrot, please \n\
-describe them as well.\n\
-\n\
-Version : " PARROT_VERSION "\n\
-Configured : " PARROT_CONFIG_DATE "\n\
-Architecture: " PARROT_ARCHNAME "\n\
-JIT Capable : %s\n\
-\n\
-Interp Flags: 0x%x\n\
-Exceptions : (missing from core)\n\
-\n\
-Dumping core...\n\
-\n",
- message,
- file,
- line,
- "(not available)",
- (int)interpreter->current_line,
- (JIT_CAPABLE ? "Yes" : "No"),
- interpreter->flags);
+describe them as well.\n");
+ printf("Version : %s\n", PARROT_VERSION);
+ printf("Configured : %s\n", PARROT_CONFIG_DATE);
+ printf("Architecture: %s\n", PARROT_ARCHNAME);
+ printf("JIT Capable : %s\n", (JIT_CAPABLE ? "Yes" : "No"));
+ if (interpreter)
+ printf("Interp Flags: 0x%x\n", interpreter->flags);
+ else
+ printf("Interp Flags: (not available)\n");
+ printf("Exceptions : (missing from core)\n");
+ printf("\nDumping core...\n\n");
dumpcore();
}
--
Andy Dougherty doug...@lafayette.edu
Nicholas Clark
> This won't necessarily work if sizeof(INTVAL) != sizeof(INT). (And since
> the prototypes are hidden in the C file, not in a shared header file, the
> compiler doesn't warn about them.) Upon reflection, however, since the
extern prototypes in a C file not in a header === bad.
Reward of 1 coffee to each person who can give any reason when it is not bad.
Can we make it a coding standard that we never define prototypes for external
functions in source files. If we need to share prototypes between more than
one source file for parrot private functions then we should use a private
header file. If we need prototypes for other people's missing prototypes then
we should do that in some sort of common header file.
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
Steve Fink
My bad. I was mindlessly propagating a workaround for a probably
long-dead problem that was hinted at in a comment. However, I'm unsure
of what the "correct" solution is. I can certainly emit the prototypes
in parrot/include/core_pmcs.h, but I long ago made pmc2c.pl emit a
CLASSNAME.h file in the classes/ subdirectory. I would really rather
use those files, but the directory structure isn't right. All parrot
..h files are now included with #include "parrot/...", and the best we
could do with the classes/ subdir is #include "classes/...".
I could have them autogenerated in include/parrot/classes/, but I
don't know if people want PMC stuff mixed in with the rest of Parrot
code. I could autogenerate them in classes/parrot/classes/ or just
classes/parrot/. Or I could take the path of least resistance and
write the prototypes in include/parrot/core_pmcs.h, but that just
makes it easier to make the same int/INTVAL mistake again, or others
similar to that.
Votes?
Btw, can anyone advise me on getting an actual account on a natively
64-bit machine somewhere? I don't really like the model of checking in
broken code, waiting for the tinderbox to get around to testing it,
blindly fixing things, and repeating. Especially when the tinderbox
machines frequently die for random reasons unrelated to the code.
Andy Dougherty
> > 64-bit-int builds appear to be broken. This is from Linux/SPARC with
> > INTVAL='long long'. This configuration used to work quite recently.
Thanks, applied
(by me).
--
Andy Dougherty doug...@lafayette.edu
Andy Dougherty
> 64-bit machine somewhere? I don't really like the model of checking in
> broken code, waiting for the tinderbox to get around to testing it,
> blindly fixing things, and repeating. Especially when the tinderbox
> machines frequently die for random reasons unrelated to the code.
Actually, you don't need a native 64-bit system. A big-endian (e.g.
SPARC) system with 'long long' is at least useful. It might be that the
Compaq "Test Drive" machines could be useful. I know little about them,
however.
I agree the tinderbox can be clunky to use, and it isn't always useful.
For example, right now, the PPC machine is still running Parrot 0.0.6
(because of the cvs repository move some time ago), and the Solaris 64-bit
machines are (apparently) core-dumping in the pointer-alignment test of
Configure.pl.
But that doesn't mean the tinderbox is useless. For quite a while, the
Solaris/JIT boxes were failing simply because of a missing test_prep
target (effectively). Once I fixed that, they suddenly started passing.
For quite a while, the systems that needed 'ranlib' were failing until I
added 'ranlib'. Similarly, the Solaris 32+64 machine is currently failing
due to a core pmc int/INTVAL mixup. I've committed my patch for that, and
you should see that machine turning green again next time it runs. When I
hacked in a crude alignment workaround, the Tru64 machines all went green.
When it was backed out accidentally, they all went orange again. So it
can be useful.
I fear we have a viscous cycle. Few people pay much attention to the
tinderboxes because so many of them are broken. You can't tell if your
change broke anything because so many of them are already broken anyway.
But few people seem bother to try to fix the tinderboxes because few
people pay attention to them. By trying to fix them, I'm hoping we can
break that cycle.
I certainly agree that blindly trying to patch something on x86 that only
breaks on 64-bit SPARC, with a several-hour-turnaround, is really really
hard, and probably a very poor use of time. However, if we can keep the
tinderbox mostly green, it can at least be useful in pointing out whether
a problem exists.
--
Andy Dougherty doug...@lafayette.edu
Garrett Goebel
>
> > Btw, can anyone advise me on getting an actual account on
> > a natively 64-bit machine somewhere? I don't really like
> > the model of checking in broken code, waiting for the tinderbox
> > to get around to testing it, blindly fixing things, and
> > repeating. Especially when the tinderbox machines frequently
> > die for random reasons unrelated to the code.
>
> Actually, you don't need a native 64-bit system. A big-endian (e.g.
> SPARC) system with 'long long' is at least useful. It might
> be that the Compaq "Test Drive" machines could be useful.
> I know little about them, however.
Looking for a good home for a Sun SparcStation 5...
My wife is nesting in anticipation of child #3. Her most recent
reorganization has displaced a Sparc5 w/ 17" monitor (i think), which child
#1 had been using for games and web access. The SS5 has a debian linux
distribution installed and is available for a good home for the price of
postage.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com gar...@scriptpro.com
Nicholas Clark
> From: Andy Dougherty [mailto:doug...@lafayette.edu]
> > Actually, you don't need a native 64-bit system. A big-endian (e.g.
> > SPARC) system with 'long long' is at least useful. It might
> > be that the Compaq "Test Drive" machines could be useful.
> > I know little about them, however.
>
> Looking for a good home for a Sun SparcStation 5...
>
> My wife is nesting in anticipation of child #3. Her most recent
> reorganization has displaced a Sparc5 w/ 17" monitor (i think), which child
> #1 had been using for games and web access. The SS5 has a debian linux
> distribution installed and is available for a good home for the price of
> postage.
Has this already been homed?
If not, is anyone able to offer it a good enough home and provide (select)
dev accounts for parrot developers to test things on?
And can it run with 64 bit addressing? (Or does that only come in with
Ultrasparcs)?
I confess I've got private access to a sun running Debian, but it's someone
else's machine, and he volunteered me access as a special favour. So I'm
not angling for an account. Also, I regret to report that I don't have
anywhere to put such a machine, and the cost of posting it to the UK would
be excessive.
To really push things too far, if the above far fetched idea could be pulled
off, then to take it one step further, having Solaris on it (and better still
if we were also able to source a non gcc compiler for it) would be actually
more useful for portability testing. But sparc debian is enough to get most
of the "x86"isms.
Nicholas Clark
PS if we could just find a test-drive Cray. :-)