Return to BSD News archive
Newsgroups: comp.os.386bsd.apps
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!pacbell.com!amdahl!netcomsv!netcom.com!hasty
From: hasty@netcom.com (Amancio Hasty Jr)
Subject: Re: [available] sound applications: xboing, tracker and NetBSD-0.8.sound
Message-ID: <hastyCE6yCs.K6n@netcom.com>
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
References: <hastyCDzwJp.9D5@netcom.com> <1993Sep27.222440.29893@ieunet.ie> <CE6K8K.xo@cbnewsj.cb.att.com>
Date: Thu, 30 Sep 1993 23:53:14 GMT
Lines: 47
In article <CE6K8K.xo@cbnewsj.cb.att.com> dwex@mtgzfs3.att.com (David E. Wexelblat) writes:
>In article <1993Sep27.222440.29893@ieunet.ie> jkh@whisker.lotus.ie writes:
>> Amancio Hasty Jr wrote in article <hastyCDzwJp.9D5@netcom.com> :
>> >If you are running XFree86 you may run into a memory leak which I fix
>> >in the mit code for XS3. Also, I doubt that Xboing will be much fun without
>> >a graphics co-processor.
>>
>> I know that, also - don't be so hasty (erm, no pun intended :) in assuming
>> that I'm running XFree86 1.3. 1.9E works great with my S3 card,
>> and with no "memory leaks" that I've been able to see.
>
>Don't YOU be so 'hasty'. Credit where credit is due. If you look in
>the CHANGELOG file in your beta sources, you will see:
>
>151. Fix for memory leak in mi backing store (Amancio Hasty)
>
>He found it, he fixed it, he told us.
>
Many thanks David for the credit and as always
I will freely give full technical details about XS3 or S3, upon
request.
This memory leak in the mit code stroke a very sore note with me.
(1) mit should have found it long time ago. Fortunatly, I think
that David also mentioned it, the X consortium has a tool to
identified memory deallocation problems. There was a
series of postings regarding this topic in comp.windows.x
little while agon on the topic: why motif or X had not been
"purified"
(2) we should have a memory tracking scheme utility such that
it can tells which routine is generating memory allocations
which are supposed to be deallocated and never are.
Setting break points and doing a stack trace on free and malloc is
not really the optimal way of tracing this kind of problems which
is what I did.
--
This message brought to you by the letters X and S and the number 3
Amancio Hasty |
Home: (415) 495-3046 | ftp-site depository of all my work:
e-mail hasty@netcom.com | sunvis.rtpnc.epa.gov:/pub/386bsd/incoming