jh@efd.lth.se (Joergen Haegg) (10/23/90)
Hello. I have found a bug in perl, well it seems to be anyway (could be the machine). If I execute any perlprogram with the '-d' option I get a floating point exception. This always occur after 'c'ontinuing from any line in perldb. The following perlscript is enough to repeat the problem: $xx = 1; Try this with 'perl -d filename'. When I continue, perl dumps. It happens in eval(), line 383. For some reason str_gnum(st[2]) returns 4294967294. The debugger tells me that this 'is not a number', and perl dumps when trying to assign 'value'. Examining st[2] shows that str_gnum is correct, it's st[2] who has incorrect values. Now this may work on other machines, but not mine. I have not seen any other having the same problem. Either that, or st[2] gets the wrong value on my machine only. I did try CRIPPLED_CC, to debug str_gnum. No difference. Perl goes thru 'make test' without any errors. This is perl3, patchlevel 36. (But the error showed up back in pl18). Host: 68010 unix sysV.2. Any suggestions? Where to look? -- -- Joergen Haegg jh@efd.lth.se postmaster@efd.lth.se System manager @ efd 046-107492 Lund Institute of Technology Sweden
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (10/23/90)
In article <1990Oct22.181253.19779@lth.se> jh@efd.lth.se (Joergen Haegg) writes:
:
:
: Hello.
:
: I have found a bug in perl, well it seems to be anyway (could be the machine).
I think it's your machine.
: If I execute any perlprogram with the '-d' option I get a floating point
: exception.
:
: This always occur after 'c'ontinuing from any line in perldb.
The line in perldb.pl that is triggering this is in the "c" case:
$stack[$i++] &= ~1;
: The following perlscript is enough to repeat the problem:
:
: $xx = 1;
:
: Try this with 'perl -d filename'.
: When I continue, perl dumps.
:
: It happens in eval(), line 383. For some reason str_gnum(st[2])
: returns 4294967294. The debugger tells me that this 'is not a number',
: and perl dumps when trying to assign 'value'.
:
: Examining st[2] shows that str_gnum is correct, it's st[2] who has
: incorrect values. Now this may work on other machines, but not mine.
: I have not seen any other having the same problem.
4294967294 is a perfectly valid unsigned 32 bit long value, the value
of ~1 (or -2 in signed longs). So the problem is after str_gnum().
The code in eval.c is:
value = (double)(U_L(value) & U_L(str_gnum(st[2])));
The value of U_L depends on how you've defined CASTNEGFLOAT, so you might
play with that. You might also try putting the value of the str_gnum()
into a temp variable, in case the problem is a too-complicated expression
for your compiler.
Larry