[701] in Zephyr_Bugs
Re: zephry 2.02
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Sep 8 13:05:57 1995
To: Dugan <dugan@austin.ibm.com>
Cc: ghudson@MIT.EDU, bug-zephyr@MIT.EDU
In-Reply-To: Your message of "Fri, 08 Sep 1995 11:51:41 CDT."
<9509081651.AA34537@centralus.austin.ibm.com>
Date: Fri, 08 Sep 1995 13:07:25 EDT
From: Greg Hudson <ghudson@MIT.EDU>
> zloc no mem(answer)
> i get everytime i execute the zlocate command. i think it is
> because the "found" variable is 0 in the ulogin_marshal_locs
> subroutine (uloc.c).
No, ulogin_marshal_locs() is only called with found equal to the
address of a local variable in the calling function, and is never
changed inside the function. Furthermore, the value of *found is
initialized to 0 at the beginning of a function, so it's not a case of
using an uninitialized value either.
Either:
(a) you're running out of swap space, or
(b) *found is climbing to some unrealistically high value.
Since *found can only increase by 1 through each iteration
of the while loop, num_locs must be unrealistically high.
If you're running the server on under SunOS or Solaris or some other
operating system which supports gdb attach, it would be helpful if
you'd build the server with debugging (make clean all DEBUG=-g), run
it, and when the problem starts occurring, attach the process in gdb
and find out the value of num_locs, as well as anything else which
looks interesting and wrong.
(State corruption bugs can be really hard to find when you don't know
how to reproduce them "in the lab", but there's not too much code
involved here, so it shouldn't be too hard.)