X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f Message-ID: <3CE2B315.7576084C@yahoo.com> Date: Wed, 15 May 2002 15:12:21 -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: emacs under w2k References: <10205151711 DOT AA14520 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: > > > So I think the next thing to find out is whether it explodes inside > > sbrk (which would mean it's our fault) or in the gmalloc/ralloc code. > > is this a traceback type abort for us? Or an NTVDM death? If it's > dieing outside our code, it could be that Win2K has bugs in the > realloc dpmi call which is used for unixy sbrk. Who knows how > often it has to move a region? > > > If the latter, I'd try to look for large positive values being > > interpreted as negative numbers. gmalloc is notorious for mixing > > signed and unsigned variables in ingenious ways. > > If built with v2.03 refresh, we shouldn't see any large positive or > negative values. > > > Btw, Charles will probably ask this at some point, so I'll answer > > proactively: Emacs sets the Unixy sbrk bit in _crt0_startup_flags. > > It would be interesting to see if clearing that caused it to behave > better (with the refresh fix to sbrk()...) Which brings up, to me, "why does emacs replace malloc etc."? Possibly it has problems with free when many blocks have been allocated, or with multiple reallocs? In both cases the problems have been handled in nmalloc, which is just standing around waiting for critical testing in the DJGPP environment. I don't think there is any foolishness about signed/unsigned sizes etc. But it has now been so long since I put it out for evaluation that I am starting to forget what went into it. I do know its total upward connection to the system is via sbrk. All else is debuggery, and disabled with NDEBUG. If the emacs module is independantly replaceable, Laurynas might want to try an immediate bodily replacement and see if the problems go away (or if new ones arise, which I doubt). Once more, available at: -- Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net) Available for consulting/temporary embedded and systems. USE worldnet address!