home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text2669.txt < prev    next >
Encoding:
Internet Message Format  |  1996-03-31  |  3.5 KB
  1. Received: from sloth.swcp.com (sloth.swcp.com [198.59.115.25]) by nacm.com (8.6.10/8.6.9) with ESMTP id KAA21618 for <executor@nacm.com>; Wed, 5 Jul 1995 10:54:08 -0700
  2. Received: from iclone.UUCP (uucp@localhost) by sloth.swcp.com (8.6.9/8.6.9) with UUCP id LAA05892; Wed, 5 Jul 1995 11:53:53 -0600
  3. Received: from beaut.ardi.com by mailhost  with smtp
  4.     (nextstep Smail3.1.29.0 #11) id m0sTYd1-000YbmC; Wed, 5 Jul 95 11:52 MDT
  5. Received: by beaut.ardi.com (linux Smail3.1.28.1 #5)
  6.     id m0sTYd1-00000BC; Wed, 5 Jul 95 11:52 MDT
  7. Message-Id: <m0sTYd1-00000BC@beaut.ardi.com>
  8. Date: Wed, 5 Jul 95 11:52 MDT
  9. From: ctm@ardi.com (Clifford Thomas Matthews)
  10. To: bartol@salk.edu (Tom Bartol)
  11. Cc: executor@nacm.com
  12. Subject: Re: E/L 1.99n broken under kernel 1.2.10
  13. In-Reply-To: <199507051711.KAA18450@pauling.salk.edu>
  14. References: <199507051711.KAA18450@pauling.salk.edu>
  15. Sender: owner-paper@nacm.com
  16. Precedence: bulk
  17.  
  18. >>>>> "Tom" == Tom Bartol <bartol@salk.edu> writes:
  19.  
  20.     Tom> Hi all, I want to second the observation that E/L 1.99n seems
  21.     Tom> to have a memory leak under kernel 1.2.10.
  22.  
  23. Right, that's what Art was running.  Mat and I are running 1.2.0 and
  24. I'm not sure what Cotton is running.
  25.  
  26.     Tom> I haven't
  27.     Tom> registered for executor yet (plan to soon, I was waiting to
  28.     Tom> see what 1.99n was like first) so I ftp'd 1.99n from
  29.     Tom> vorlon.mit.edu, installed it (BTW I like the makefile
  30.     Tom> installation procedure), and fired it up.  I get the splash
  31.     Tom> screen and hit "demo" and then watched my xsysinfo swap usage
  32.     Tom> indicator grow and grow and GROW.
  33.  
  34. I just ran E/L 1.99n over here while running top.  I think we have a
  35. small memory leak each time a new application starts, but it's on the
  36. order of 1k per application -- any leak is a bad leak, but we're
  37. definitely seeing different memory footprints on our different
  38. kernels.
  39.  
  40.     Tom> Finally I just killed the
  41.     Tom> process.  Thinking that perhaps incompatible bits of 1.99m
  42.     Tom> were left hanging around after installing 1.99n over the top
  43.     Tom> of it, rm'd the entire executor install tree and installed
  44.     Tom> 1.99n clean and fresh with the same final results.  So, like
  45.     Tom> I said I am planning to register right away and I would be
  46.     Tom> more than happy help ARDI focus on squashing this bug.  I
  47.     Tom> imagine it really is something having to do with kernel
  48.     Tom> 1.2.10.  Tonight I'll switch back to 1.2.8 and also to 1.2.11
  49.     Tom> (or 1.2.12 if such an update comes out later today) to try to
  50.     Tom> narrow this down a bit.
  51.  
  52. That would be very handy.  If anyone out there is running 1.2.10 and
  53. *not* seeing the memory leak, that would be handy as well as any
  54. information from anyone running > 1.2.10.
  55.  
  56.     Tom> I running on a 486/66 with 16 Megs,
  57.     Tom> ATI Mach32 Graphics UltraPro with 2 Megs, and Slackware
  58.     Tom> 2.3.0.
  59.  
  60. Mat and I both use ATI Mach32 cards on 90 MHz P5s.  Mat's machine has
  61. 32 MB, mine, 24.  I think he has 2 MB VRAM, and I have 1 MB.
  62.  
  63.     Tom> And while I'm at it, I'd like to take this
  64.     Tom> opportunity to offer my most profuse thanks and praise to
  65.     Tom> ARDI for such a killer product! (my probelms with 1.99n
  66.     Tom> notwithstanding).
  67.  
  68. Er, I'm not sure that "killer" is the best adjective for a program
  69. that apparently consumes vast amounts of memory under some kernels.
  70. Too early to tell whether the kernel hypothesis is true, but if it is,
  71. and it's our fault, you can see how this could have slipped by.
  72.  
  73.     --Cliff
  74.     ctm@ardi.com
  75.  
  76.