From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.17-14 i686) the getty and uugetty executables both segfault with no debugging data if they are given a 'speed' label command line option which does not exist in the /etc/gettydefs. Reproducible: Always Steps to Reproduce: 1. make sure no "DT115200" entry exists in your /etc/gettydefs 2. either run getty from the /etc/inittab with an entry like this: S1:2345:respawn:/sbin/getty ttyS1 DT115200 vt520 or from the command line like this: % /sbin/getty ttyS1 DT115200 vt520 Actual Results: when run either from inittab or from command line, the system log (/var/log/messages) will show an entry like this: <date> <hostname> getty[<pid>]: Segmentation fault when run from the inittab of course, it will produce several entries like the above (not just one, as with command line execution), and then INIT will shut it down for 5 minutes. then it will respawn and you'll see the same errors again. INIT's respawning notices will appear on the system console on the stderr. Expected Results: when program cannot find supplied speed entry in the /etc/gettydefs, it should a) check whether the supplied speed entry exists in the /etc/gettydefs, b) log an error to the system log saying something like: <date> <hostname> getty[<pid>] cannot find speed label: "DT115200" does not exist in /etc/gettydefs c) exit gracefully. (without the above, i spent a whole day debugging this problem). 1) also, in packing the rpm (getty_ps-2.0.7j-12.i386.rpm), you have omitted the author's original source site from your rpm info (rpm -q -i getty_ps). also, you have omitted the author's .lsm file from your distribution. this means it was impossible for me to locate the source (for additional info/hints/etc) through your .rpm itself. it took quite a while for me to locate it (and i didn't want to download and unpack your .src.rpm, and many people might not even know about these) 2) i am also sending the the author, Kris Gleason, a more detailed email message describing the problem and some additional info, including performance when run from his supplied pre-compiled binary, etc. 3) problem originally surfaced when we moved a vt520 terminal from one linux box to the other and didn't *also* copy the special /etc/gettydefs entry (DT115200) we use for that terminal.
getty_ps is passing some rather silly flags to the compiler. Will be fixed in the next getty_ps build, but it may be a real compiler bug. Jakub: it segfaults when trying to syslog the error (table.c:272) when compiled with -fomit-frame-pointer.
Smells like a gcc bug, but it looks like it is present in all of egcs 1.1.2, gcc-2.95.2, gcc-2.96-RH and gcc-3.1 CVS. Will try to reduce it even more than I have done already and try to fix it.
This is not gcc bug, table.c is doing horrible things like writing before start of a buffer or not terminating a buffer after strncpy: --- getty_ps/table.c.jj Tue Feb 27 12:45:37 2001 +++ getty_ps/table.c Tue Feb 27 18:40:00 2001 @@ -78,9 +78,11 @@ int mode; } /* get the first (label) field */ - (void) strncpy(buf_id, buf, MAXID); - if ((p = strtok(buf_id, "# \t")) != (char *) NULL) - *(--p) = '\0'; + p = buf + strspn (buf, "# \t"); + (void) strncpy(buf_id, p, MAXID); + buf_id[MAXID] = '\0'; + if ((p = strpbrk (buf_id, "# \t")) != NULL) + *p = '\0'; /* if Check is set, parse all entries; * otherwise, parse only a matching entry */ (I've sent this in email as well, because this one will have whitespace mangled).
This was fixed; the fixed package should have been in rawhide.