3.35 vs RH Linux 7.0

From: Terry R. Friedrichsen (terry_at_venus.sunquest.com)
Date: Tue Jan 02 2001 - 14:48:34 GMT

ups 3.35 had some compilation problems on RedHat Linux 7.0.  I'll report
those separately if anyone is interested.  (Not the least of these is the
fact that all the MENU structures in menudata.c are initialized incorrectly;
the initializers are too short and are missing an element in the middle and
at the end.  This didn't have any effect on ups, though ...)

The major problem is that it gets

	Fatal internal error: bad number in parse_num (aborting) ...

most of the time when you try to examine a variable.

Here's what I've learned so far, by hacking a couple of printfs into 

in parse_number with 3)
in parse_number with 5,30)=(5,31)=s8__val:(5,32)=ar(5,33)=r(5,33);0000000000000;0037777777777;;0;1;(0,1),0,64;;
in parse_number with 30)=(5,31)=s8__val:(5,32)=ar(5,33)=r(5,33);0000000000000;0037777777777;;0;1;(0,1),0,64;;
in parse_number with 5,31)=s8__val:(5,32)=ar(5,33)=r(5,33);0000000000000;0037777777777;;0;1;(0,1),0,64;;
in parse_number with 31)=s8__val:(5,32)=ar(5,33)=r(5,33);0000000000000;0037777777777;;0;1;(0,1),0,64;;
in parse_number with 8__val:(5,32)=ar(5,33)=r(5,33);0000000000000;0037777777777;;0;1;(0,1),0,64;;
in parse_number with 5,32)=ar(5,33)=r(5,33);0000000000000;0037777777777;;0;1;(0,1),0,64;;
in parse_number with 32)=ar(5,33)=r(5,33);0000000000000;0037777777777;;0;1;(0,1),0,64;;
in parse_number with 5,33)=r(5,33);0000000000000;0037777777777;;0;1;(0,1),0,64;;
in parse_number with 33)=r(5,33);0000000000000;0037777777777;;0;1;(0,1),0,64;;
in parse_number with 5,33);0000000000000;0037777777777;;0;1;(0,1),0,64;;
in parse_number with 33);0000000000000;0037777777777;;0;1;(0,1),0,64;;
in parse_number with 0000000000000;0037777777777;;0;1;(0,1),0,64;;
in parse_number with 0037777777777;;0;1;(0,1),0,64;;
in parse_number with ;0;1;(0,1),0,64;;
parse_number is about to choke on ;0;1;(0,1),0,64;;
Fatal internal error: bad number in parse_num (aborting) ...
Dumping core ... Abort (core dumped)

It looks as though the code is totally unprepared to see two semicolons in
a row.  At this point, I haven't dug into the code far enough to determine
whether the problem is with the code or with the string it's trying to eat.

If anybody can toss me a clue as to what those strings are *supposed* to
look like, I'd appreciate it.


Terry R. Friedrichsen


This archive was generated by hypermail 2.1.4 : Wed Feb 13 2002 - 21:51:33 GMT