Date: Tue, 3 Sep 2002 20:32:48 +0200 From: Thomas Moestl <tmoestl@gmx.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Peter Wemm <peter@wemm.org>, ticso@cicely.de, Alexander Kabaev <ak03@gte.com>, ticso@cicely5.cicely.de, des@FreeBSD.ORG, current@FreeBSD.ORG, dillon@FreeBSD.ORG Subject: Re: alpha tinderbox failure - kernel is broken. Message-ID: <20020903183248.GC441@crow.dom2ip.de> In-Reply-To: <200209031821.g83IL5Wd058341@apollo.backplane.com> References: <20020903161933.GB80508@cicely5.cicely.de> <20020903163714.049602A7D6@canning.wemm.org> <20020903175819.GA441@crow.dom2ip.de> <200209031821.g83IL5Wd058341@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2002/09/03 at 11:21:05 -0700, Matthew Dillon wrote: > > :The attached patch does just change the heuristics used to detect > :"text" segments to look for executable segments (using an idea from > :Peter). This results in the fact that dynamic section is viewed as > :text, which should not break anything. > :This way, it should be possible to avoid the hole currently; a real > :fix would be to add a new vmspace field to represent the heap size > :including holes which could then be used by obreak(), while vm_dsize > :would only be used for statistics (which is however difficult to > :maintain when shrinking below the initial size with brk()). > : > :Can somebody who is feeling adventurous and has an alpha box please > :test whether this fixes it for now? > : > :Thanks, > : - Thomas > > Excellent Thomas! Thanks for tracking this down. Your patch looks > far better then mine if the circumstances of the failure are as you > believe. > > As soon as we get verification that your patch solves the problem, > I will commit / MFC cycle it. > > I am also still somewhat worried about the data segment start address > and I am wondering if I should remove the if (data_addr == 0) > and instead unconditionally set data_addr to the last data segment > loaded (which is what the original code did). That would only allow to shrink bss, but since that seems to be the traditional behaviour (and it's not likely that anybody would like to shrink away other segments), that would probably better. I think this would also require to add that other vmspace field as I described above, otherwise there would be a gap between bss and the heap start because vm_dsize counts all data segments. However, it has the advantage of making this real (non-workaround) fix easy to implement, since no bookkeeping problems would occur when shrinking just bss away (as no holes can be crossed). - Thomas -- Thomas Moestl <tmoestl@gmx.net> http://www.tu-bs.de/~y0015675/ <tmm@FreeBSD.org> http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020903183248.GC441>