mark@zok.UUCP (Mark W. Snitily) (12/11/90)
I email the following bug fixes to the author of xdbx, Po Cheung, a
couple of weeks ago but haven't heard anything back. Assuming that
the email got lost, I'm now posting them to the net. If anyone knows
Po, please forward these to him. The email addresses for Po that I
used were: "cheung@sw.mcc.com" and "po@cerc.utexas.edu". Thanks.
This is a bug report for Xdbx 2.1 patchlevel 2. Platform was a Sun 3
and a Sun 4 both running SunOS 4.0.3 (but these bugs are independent
of the HW and OS).
Problem: xdbx sometimes dumps core changing the current directory when
using the file browser. Only happens when system is heavily
loaded.
Bug #1, (only occurs because of Bug #2): -------------------------------------
In funtion pwd_handler (in file handler.c) it is possible for its
argument to be a null string (see bug #2 below). When this happens
strtok() returns NULL and the following strcpy causes xdbx to dump core.
Here's a context diff that prevents the core dump. After fixing bug #2,
this problem goes away, but might as well add this code in for safety.
(Also note that leaving "cwd" unaltered is also logically correct since
"s" == "" implies we don't have a new current working directory yet.)
*** handler.c.org Fri Aug 24 00:26:31 1990
--- handler.c Fri Nov 30 18:49:52 1990
***************
*** 426,432 ****
void pwd_handler(s)
char *s;
{
! strcpy(cwd, (char *)strtok(s, "\n"));
}
/* ARGSUSED */
--- 426,434 ----
void pwd_handler(s)
char *s;
{
! char *s1 = (char *)strtok(s, "\n");
! if (s1)
! strcpy(cwd, s1);
}
/* ARGSUSED */
Bug #2, (a real hard one to track down): -------------------------------------
The reason why pwd_handler received a null string is because function
read_dbx (in file "dbx.c") read the string returned from "pwd" and then
exited before the "(dbx)" prompt was available from dbx. read_dbx was
called again at least once before the "(dbx)" prompt was read. The side
effect of this is that "s" was null from the fgets and the null "s" was
concatenated to "output".
In function concat (in file "utils.c"), if the second string is null,
then the first string is set to null. That's how the null string was
created that was eventually passed to pwd_handler. After applying the
following patch, function concat will simply return the first string
if the second string is null. Here's the context diff:
*** utils.c.org Fri Aug 24 00:26:33 1990
--- utils.c Fri Nov 30 23:58:40 1990
***************
*** 128,134 ****
strcat(s1, s2);
}
}
- else
- s1 = NULL;
return (s1);
}
--- 128,132 ----
Believe me, this took a *long* time to track down. Thought it was due to
nondeterministic execution of xdbx and dbx (bug only occurred on a heavily
loaded system where processes were swapping). But no, it was just a simple
string concatenation problem. Oh well...
Once again, if anyone knows Po, please forward this so that it ends up in
an official version. Thanks. I *really* don't want to see this bug again...
-- Mark
Mark W. Snitily Consulting Services:
894 Brookgrove Lane Graphics, Operating Systems, Compilers
Cupertino, CA 95014 (408) 252-0456
mark@zok.uucp West Coast UUCP X11 archive site
If your mailer doesn't like the .uucp domain, these also work:
...!{mips,sgi}!zok!mark, mark%zok@mips.com, mark%zok@sgi.com