load_region() problem :(

[Torsten Scherer <itschere@TechFak.Uni-Bielefeld.DE>]

 Hey you all!

 Now perhaps someone here can help me 'cause I'm desperate now. Situation is
that I had a heavy net-session just some hours ago with lots of logins (Benni,
can you hear me? ;) and daemon calls. This very quickly leads to a terribly
fragmented memory. Sad enough, but uncureable though.

 But the mysterious thing is that even if there's enough ST-RAM available
-mbaserel clients which are set up to run in TT-RAM are just `killed' if
TT_RAM is getting low. `Enough' in this context means two or three 500k
blocks of ST-RAM where a ~80k program wants to be started in TT-RAM.
Increasing the debugging level only prints `pexec: load_reagion failed'.

 If I change some TRACEs to DEBUGs and add some DEBUGs to get some more
specific information it shows that in fact create_base() in mem.c fails
when it is called in load_region() near this:

	env->links++;
	if (s && !shtext) {
>>>		reg = create_base(cmdlin, env, fh.flag, size,
>>>			isexec ? curproc : 0L, s, f, &fh, xp);
		shtext = s->text;
	} else {
		if (shtext)
			shtext->links++;
		reg = create_base(cmdlin, env, fh.flag, size,
			isexec ? curproc : 0L, 0L, 0L, 0L, 0L);

 Further investigation prooved that create_base() really sucks near:

	if (s && !s->f) {
		if (!s->text) {
			m = addr2mem(alloc_region(map, len + fh->ftext + KERNEL_MEM, protmode));
			if (!m ||
			    (((len > minalt &&
				((flags & F_MINALT) < F_MINALT) &&
				max_rsize (map, -1) < fh->ftext) ||
			      0 == (s->text = addr2mem(alloc_region(map, fh->ftext, PROT_P))) ||
			      (m->next == s->text &&
				!(detach_region (curproc, s->text), s->text = 0))) &&
			     shrink_region(m, fh->ftext))) {
				if (m)
					detach_region(curproc, m);
				kfree (s);
				mint_errno = ENSMEM;
>>>				return 0;
			}

 Which is where I stopped because it's late at night and I'm obviously not
familiar enough with all this. Since all these routines deal with shared
text regions it seems to be a specific problems of these. In fact it looks
like the strange F_MINALT flags from the program header suppress create_base()
to look in every possible map.

 I think this F_MINALT stuff is a *bad* idea. A program which wants to be
loaded into ST-RAM doesn't need them and a program which wants to be loaded
into TT-RAM should be able to deal with all possibly arising memory problems
anyway (say can't rely on that it really gets there), so what's the point of
actually doing something like this? Now please don't say it's a contribute to
old GEM programs or things like these...

 Heaven help! Will there ever be a version of MiNT with virtual memory? For
the very beginning it would already be very sufficient not to implement
swapping but just to implement a virtual adress space to avoid memory
fragmentation.

 But this will probably also fail due to some stone age software... :(

a bit down once again,
TeSche

PS: `a bit down'? no, not really. in fact `totally discouraged'...

PPS: Ah, well, this happened with MH-MiNT 1.12, but if I remember correctly I've
also had this problems with all versions before, only that this was the first
time my system was under such a heavy load it nearly trashed the thing...