X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f Message-ID: <3CC3EFC1.754DB126@yahoo.com> Date: Mon, 22 Apr 2002 07:10:57 -0400 From: CBFalconer Organization: Ched Research X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: Malloc/free DJGPP code References: <10204220408 DOT AA16715 AT clio DOT rice DOT edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Charles Sandmann wrote: > > > I put a whole bunch (of benchmarks) up earlier using a/b > > comparisons on my machine with some of my software. I am > > impressed by the apparent NIH syndrome, and am not especially > > motivated to contribute further efforts. This is the first time > > anyone has shown any signs of even reading the code > > Please be patient. At least in my case, this isn't a NIH syndrome I did qualify with apparent. It just seems to me that someone somewhere would have compiled it and tried it out. Instead, dead silence. ... snip ... > > Please don't be discouraged from your contribution's slow pace. If > you were to go away today and never come back I'd probably eventually > review/tweak the code to get it into CVS myself. The free problem is > a real one due to a poor algorithm, and I appreciate you taking the > time to look at it and provide a fix. Sticking around and bugging > gently will help it get done more quickly, and you can help us > provide a higher quality product. > > That still doesn't mean I think it's time to check it in without more > testing. In particular, I don't know what would happen if you got > a sbrk() sequence that looked like: > 0x00010000 > 0xfffd0000 > 0x00020000 > 0xfffe0000 > In other words, addresses which are not strictly increasing, and can > include values which mess up signed/unsigned comparisons, and can mess > up sizing quite a bit. This sequence above can be caused under Windows > in the right conditions. If we haven't tested in that case, I'd be > scared to release it - since it has broken previous malloc() packages. I considered it, but did not test for it exclusively. I believe there is nothing in the code to cause a problem, and there is a comment about precisely that just above the actual nmalloc function code. I have taken pains to do arithmetic with byte* pointers, where byte is a typedef for unsigned char. The use of sbrk is limited to the extendsbrk function, which also handles alignment, and only cares whether or not the expected value is returned. Unexpected values lead to greater fragmentation, and I have never seen unexpected values under W98 AFTER initialization. The initialization code appears to leave various little pieces in odd corners, all of which is grist for the mill. If anything were actually happening it would be trivial to add just such a test to the fakesbrk generator in tnmalloc. As it is, I shall avoid disturbing anything unless I decide a real bug exists. It is hard to test/evaluate a moving target. Notice that there is a serious realloc problem with the existing code, as shown by the evilalgo program. I have not bothered to look for the causes in the original, but have shown that the problem does not remain in nmalloc. I did add the evilalgo source to the zip file and some make targets. -- Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net) Available for consulting/temporary embedded and systems. USE worldnet address!