[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Memory problems
sjg@phlem.ph.kcl.ac.uk writes:
> Is anyone else having the same problems with memory that I get running the
> init suite of programs?
>
> When I run tcsh as the 'init' program from mint.cnf, I have something like
> 3.6Mb left over to play with. Not bad from the 4Mb it started from. The
> problems come when I try the multi-user approach. When I log in having started:
>
> o init (and therefore update)
> o virtual consoles (4 of them - 4 getty's)
> o syslog
> o cron
> o lpd
>
> and 1 tcsh on (say) vt01, I have 1.6Mb free(!!!).
is that all free blocks (df /proc) or just the largest one? (Malloc(-1)...)
> The memory usages of the
> programs (as given by ps) come to around 1.2Mb. That ought to give me over
> 2.5Mb to play with.
also ps doesn't show everything, like kmalloc()d space (used by
kernel, devices, filesystems...) try ctrl-alt-f5, and (MiNT 1.09)
ctrl-shift-alt-f5 (-> debug.c, mem.c, nalloc2.c).
>
> Another thing is that when I run a tcsh on another terminal, and type 'mem'
> the memory available has gone down (surprise :-), but when I press CTRL-D to
> logout, and look at the memory available from the first terminal, it stays at
> or about the level it was when 2 were running. Eventually I run out of memory.
i don't know how tcsh's `mem' works, if its only the largest free block
this doesn't have to be a real leak, maybe its `just' fragmentation...
if you fix this, :)
Index: vcon.c
@@ -86,15 +86,15 @@
if (cfd >= 0) {
/* try to uninstall gracefully... */
int opencnt = 0;
- char *vt00name=ttyname(cfd), *oldcname=ttyname(0), *s;
+ char *vt00name, *oldcname, *s;
long vpgrp;
/* /dev/vt00 might be renamed /dev/console... */
- if (vt00name && (s = strrchr (vt00name, '/')) &&
+ if ((vt00name=ttyname(cfd)) && (s = strrchr (vt00name, '/')) &&
!strcmp (s, "/console"))
rename (vt00name, "u:/dev/vt00");
/* move original console device in place */
- if (oldcname && (s = strrchr (oldcname, '/')) &&
+ if ((oldcname=ttyname(0)) && (s = strrchr (oldcname, '/')) &&
strcmp (s, "/console"))
rename (oldcname, "u:/dev/console");
you should be able to do a simple test: login, go single user
(SIGINT init, should shut down everything and give you a root sh,
unless GEM was running... :( ) do a df /proc there, leave single user
mode (exit sh) and do the same thing again. i get the same result both
times, if you don't maybe you can compare atrl-alt-f5 output and find
the leak that way...
>
> Presumably the memory used has not been reclaimed somewhere along the line, or
> the free-memory management isn't working properly. Any fixes/ideas welocme :-)
if your running 1.09, do you have the nalloc fixes installed?
~Subject: nfree patch (memory fragmentation...)
~To: mint@terminator.rs.itd.umich.edu
~Date: Thu, 19 Aug 93 23:23:22 CES
~From: Juergen Lock <nox@jelal.north.de>
~X-Mailer: ELM [version 2.3/ST PL11]
~Message-Id: <9308192123.AA00114@jelal.north.de>
i just had it again, some memory chunk left in the middle of nowhere...
looked again at the 1.09 diffs, hit ctrl-shift-alt-f5:
pid 4 (ksh): Arena at 1122A4 size 6000: free list:
pid 4 (ksh): 112DC4 size 0
pid 4 (ksh): 112E18 size 0
pid 4 (ksh): 1133CA size 4
pid 4 (ksh): 113468 size 8
...
pid 4 (ksh): Arena at 1AC988 size 4000: free list:
pid 4 (ksh): 1AC994 size 3FEC
strange, a 4000 long area with 3fec free... here's a patch :-)
--- nalloc2.c_ Tue Aug 17 18:36:30 1993
+++ nalloc2.c Thu Aug 19 21:46:12 1993
@@ -239,7 +239,8 @@
/* if, after coalescing, this arena is entirely free, Mfree it! */
if ((struct arena *)a->a_ffirst == a+1 &&
- (a->a_ffirst->b_size + sizeof(struct block)) == a->a_size) {
+ (a->a_ffirst->b_size + sizeof(struct block) + sizeof(struct arena))
+ == a->a_size && a != a_first) {
NALLOC_DEBUG('!');
*qa = a->a_next;
#if 1
btw i later also found what looked like kmalloc'd pathnames of
nonexisting files that the shell must have searched earlier... is
it tosfs that keeps them? why? :-)
------------------------
~From: Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>
~Date: Mon, 6 Sep 93 10:45:09 +0200
~Message-Id: <9309060845.AA20726@issan.informatik.uni-dortmund.de>
~Received: by issan.informatik.uni-dortmund.de id AA20726; Mon, 6 Sep 93 10:45:09 +0200
~Reply-To: schwab@ls5.informatik.uni-dortmund.de (Andreas Schwab)
~To: mint@atari.archive.umich.edu
~Subject: Bug in MiNT 1.09
There is a serious bug in kmalloc: when allocating a new arena for
nalloc, the size passed to nalloc_add_arena is too big!
--- orig/util.c Tue Aug 17 21:23:28 1993
+++ util.c Sat Sep 4 22:06:36 1993
@@ -156,7 +156,7 @@
lp = (long *)m->loc;
*lp++ = (long)KMAGIC;
*lp++ = (long)m;
- nalloc_arena_add((void *)lp,KERMEM_SIZE);
+ nalloc_arena_add((void *)lp,KERMEM_SIZE - 2*sizeof(long));
goto tryagain;
}
}
and while your at it you could also increase the initial KERNEL_MEM
(mem.h), i have it at 6*QUANTUM...
>
> Simon.
may the source be with u :)
Juergen
--
J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
...ohne Gewehr
PGP public key fingerprint = 8A 18 58 54 03 7B FC 12 1F 8B 63 C7 19 27 CF DA