Is undump really supposed to be
saving ALL of bss? I am a bit
suspicious that this should NOT be the case, since getloadavg is one of
the files linked in after the marker
symbols in lastfile.c.
I don't know why this is; perhaps the linker reorders things.
One easy solution
The immediate problem can be worked around by building emacs
as a user who has no access to /dev/kmem (normal users do not).
This causes getloadavg to fail before emacs undumps, leaving
state initialized properly for operation after the undump.
Let's implement code to prevent getlo
Richard Stallman wrote:
> However, there is probably a flaw in undump here that is likely
> to cause other problems. It appears that state is being preserved
> across undump that should not be.
>
> We have to depend on AIX users to debug this.
> Can you describe the symptoms?
>
> Meanw
However, there is probably a flaw in undump here that is likely
to cause other problems. It appears that state is being preserved
across undump that should not be.
We have to depend on AIX users to debug this.
Can you describe the symptoms?
Meanwhile, I am sure it is possible to make
The immediate problem can be worked around by building emacs
as a user who has no access to /dev/kmem (normal users do not).
This causes getloadavg to fail before emacs undumps, leaving
state initialized properly for operation after the undump.
However, there is probably a flaw in undump here that
Emacs 22.0.90 pretest built under AIX 5.2 brings up an X window then
exits. I did some debugging and it appears to be a problem with undump --
the state variables used internally by getloadavg() are being preserved,
which causes the first call to getloadavg to malfunction and close
the socket to t
