From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 20 03:20:42 2021 Received: (at submit) by debbugs.gnu.org; 20 Jul 2021 07:20:42 +0000 Received: from localhost ([127.0.0.1]:60893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5k3W-0007fj-0q for submit@debbugs.gnu.org; Tue, 20 Jul 2021 03:20:42 -0400 Received: from lists.gnu.org ([209.51.188.17]:37936) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5k3U-0007fc-De for submit@debbugs.gnu.org; Tue, 20 Jul 2021 03:20:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44894) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5k3U-000081-8S for bug-gnu-emacs@gnu.org; Tue, 20 Jul 2021 03:20:40 -0400 Received: from smtp6.ctinetworks.com ([205.166.61.199]:59514) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5k3S-0003Pk-Lk for bug-gnu-emacs@gnu.org; Tue, 20 Jul 2021 03:20:40 -0400 Received: from localhost (unknown [117.193.82.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: enometh@meer.net) by smtp6.ctinetworks.com (Postfix) with ESMTPSA id A30AC84B2C for ; Tue, 20 Jul 2021 03:13:32 -0400 (EDT) Date: Tue, 20 Jul 2021 12:43:31 +0530 (IST) Message-Id: <20210720.124331.173592885202931943.enometh@meer.net> To: bug-gnu-emacs@gnu.org Subject: more data on #43389 From: Madhu X-Mailer: Mew version 6.8 on Emacs 28.0.50 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Jul_20_12_43_31_2021_790)--" Content-Transfer-Encoding: 7bit X-ctinetworks-Information: Please contact the ISP for more information X-ctinetworks-MailScanner-ID: A30AC84B2C.AB65C X-ctinetworks-VirusCheck: Found to be clean X-ctinetworks-SpamCheck: X-ctinetworks-Watermark: 1627629219.79031@PTDsX+Zq8uJgsHH7YPIbdQ Received-SPF: pass client-ip=205.166.61.199; envelope-from=enometh@meer.net; helo=smtp6.ctinetworks.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) ----Next_Part(Tue_Jul_20_12_43_31_2021_790)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is the emacs memory bloat issue. I thought I had unarchived the bug earlier but it seems to be closed up again. Should I open a new bug? Its already got a 1000 posts on the bugzilla page Over the past few months, I've experienced the memory problem a few times. I wanted to share the malloc info data I collected on 3 instance and am attaching a tarball with 3 directories named 4 5 6 which include malloc-info, memory-usage, and memory-report data from emacs exhibiting the behaviour - after all buffers are killed and after an M-x gc. Directories 4 and 6 show the common pattern where memory is used unknown to GC. data in directory 5 probably another issue where there are a lot of dead strings. I'd be glad if/when experts can find the time to take a look and see if it offers any further clues. ----Next_Part(Tue_Jul_20_12_43_31_2021_790)-- Content-Type: Application/Octet-Stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="madhu-emacs-malloc-info-data-20210719.tar.gz" H4sIAAAAAAAAA+xda4/ctpL11+5fQfjeD84k3eH7YdjB2o7XMDZOFvHNRYAgCDQzmple92PQ3ePH /votSiRV6q7WtG+SucBmBMSjlkiRqiJPFYtHlUV1fnUzqRfV2WayqObz1dlktrxYTc6rbTWRXAru RPj6we86OBzOmPav1c1fodu/6XggNBTRVmupHnBhFdcPmPl9zR533Gy21ZqxB4soiMFy9XpzFx26 22NxlP5/fPns2zcvp6v15b/SRlSwTfom9C+kEkX/ynLQv3PaPWD8j35Z6viL6/+ELerFav2JRa2v F9V2tloyOGN/00r5MB6fnLCz1XJbL7eb8flsXZ9tV+tZvWG//HIxm9eP9a+/6F9/zb/Mr7+Y7pf9 9RcLv+rq7Kp5RjVbjrdX67pm8fbm8XjCGBpz04+LOZuwi/Vqwd5MPuJbTcmmn5ObTXVZT7cft2zS lUS3UNF1fb1ab9uybLdwd3M8fr1Mnaw2NWvmAvtQbVgcGdv6nFWb8d++fP7y1evvf3v74wu2uRq/ efbddz+8+O3Zjy+/f/bbm2c/P5Wp2sO//8dDKPzy+29j0UZ6y9W23kCvsPA0q5bnzMKjVh9YBcJZ LEDs19V2W6+X7MNVva7ZzbI6O1vdLGMP1vVmdg4qGGdlbVgjnCre/HA1g77DJWiJvZ9tZqfzmm1X 7NWLKWr2EzNNc5vYXnzPtpVt828V/2NzqL+6YOd1dQ7vvp4tLzfT5hXad3sPEwBGx/jV9z+xl80V 6ad8ajh7dHozm58z8RX76O1vVk+uzybz2fLm4+RyefMV+xl6s5q/m22/gpZn61V+EhNTYaccClQf FDR5tl7N5+y0Wm++GI//3RPjL3Ich//6d3kAR9p/JZV2zppo/7UR9/b/Lo5j9b+Lvp/Txi32H1rR nf6FewCtWnFv/+/keFWtT0GlYILmc7ATEZVBIFswzo8egc3egLESloWgjPXMes69+YI92nxanK7m YMfgmlbcMulUvNwaDaYkA3WCE8e00MKVO5PTT9v4QChunPcq1nnfWKe2FQ9uf7k02YA92jDPJDxD ccUkPNNYuH8xX1XNHSHA+IigPVycgaFcv6+gU8YyGE0SKqpgxBfROl1cgPLgLSQT6gswLuzpNyNh pvLNc/boSyb4VMNZtHtfgB/E2vcej+Q06FRCTv07VCK9/3gEN1QqMpUWPyTJAp5imyLlUisEqAqW s72eRACXbPc0r/DTsEjGIz8NsTuxHLwE7lgrmvGIOeve5X55/KQip6bz9l3TgySh8fgfq201j1fm s801W53+D7S7ecwCn4rYsfnsfc2cib38qvUThJ7C40Gkz5tHsHWDIdmpbODi8Vio0oIJjSS3TTuP jJ26tgeX1TVYfdYcb2f/W49eVdej76tFPU4XhXR85IwYnbypN/Gxm5N0h1lnQJtOj05SJ76twdec owLKj4TwUOzkdduRcktLORLBi9F5fXpz2QPCXES4WCSokc5XmHdwRYXRyYvV4npex2nTtcYYHwlu uRuxkzez5QxanIjeXcnh1suzqxV7tq4rRtwEsHmPelmuv63eg8f33/PqrN7s3DW691C+Xzl3ZueW EZaD6Kqzd9s1PPfk3vX6Cx2faf+7VdNntHGb/XdO9v0/KblW9/b/Lo6Xm+1s0Swj2yXdmxa4f2qW 0gATAPaWvZk9Z+wHACQYIOyHxij0C7JoB1K5H+sGvM7Zo+c3W/bTEgQHlqdXK5ZXU9OWLw+CKs8/ sVfz1SmYhn9W61kFC9lNhCo3FWTZt40ZBjicbcDoMW3UVLP/igVbO5bMwU5Xo0nEpV4vogP0ojq7 qhvTMx6nzr4Fk5vEoHx+vbfJrke7MPXttX8mA86iPVbttRetEwHNgRuRqiavgXkbprztwutijqGy BZk0V9uOT9p+NA8Bk9/e+s/Wwo+/q9ZgA7epKFwA/8jlF2sGM1QzMgsEGz6tcjsY9ZvrqfSO4Yp+ SXuDtJLw0qlz0UKCN+XbX02x6Xx12epQ71x9Ir+JN0zp4q4xVVOXXmdn8dHeFKlazx+QWQT7tlDk lzhJA+LHBsyae5yqJnZv7VlfdA9ZbHQVmdyisW5ot73S7egAvZ5PrmAktxOk6W5z4++xl/CCkxju uYyCuAatxQtL8I9gdICXC6OzafHL+QfQy/KmmrcI7iZiwif8SyikQ5bYJczJCdRfbifVejs7m9eT Kk4hGJg+ZG1c18vz6K3eLM9Xk/au1Ta3EyNW1RL113iTHz97/2kCD5xDf+ER0I3YR8XLrLsA8U2W 9YfJxRr6PzmvL6qbeRzl0ss8kK7q+XW8A+KL42FyvYbzj/FBUpXBCECxXlfQuLBlBG5ARZPrqKH8 TkKXobJaw9hdbuGR8UmiG9ZNl9/P1tsouOyqMpBZnqaXDSqBaK97lz/Mzi/r7aR3F0SYnno6O93W HyfwZ17FE2galJe6xXyZhW2DjTbRAID7SWDzD48fJ6XmhQfcLiO9UefmBhQCT1+szuvcEZ6FcrZq VLn5tNnWi9SB5OUdbf/7cdrPsjG32H+nhS32H5yBuP7XXNzb/7s4nrSKzSHZpw/Fw2/GT67q6pot 108f8vhrA0ZxE7G6OWsi6U8fKvUQVnH5L9hROA3cGPOQNVFreJLwyjz8ereiDm3F9m9TUVqhrS4V jVJ2v54Xbb32b1PPS2181x4Xfr9acG219m9TTYSuLblfQ4j0aumkqWNs92LESwmZ3iqdtK8VXAhd S0oQ9bRJ9dqTti2A4cBLRc0t1Uub5JFO2hZhWhnZVRVKwa/9ui4JJZ20daWWpuuukNYRNUOWTehk o6W2XZuSalHyJJ900upB6ICkSohVyiSedNJWUwZW/KWe5YqoqJN00klbUXspUEVBtWiSaNJJquhk lHLuqaNadEky6aSpGIyMEk71FAz5/Xo+S8Z3kjFScaQKT4wcxZNo0kmrCRsc0r7RRD2ZJJNO2nrK CzTAhbKEaJRyeco71FPtcFeNIUaNMhksTCcbGWOJnXCMJYSjbBJOOkmdlV45BDOUOpTP4vFoYmmt 0MQSWhACAtOTAIoL9JrOCYsEJAiE0iIJKJ20Y4dL49GUbObKftWCiggWm/PcIvGKokhHIaSyMMqH 4E3bPMS1RUMuKG2HqhmXYTGftYJpfhzupLBFnrCot50upFAeTL5A6oAZQEKHyaBTTtMAan4dblva rqbFNY0SfvBl4X6eluW0NXHtrwGlKJ6hRymDpqYE9wbBKzVLbMhWJEa6u+6K4JUWQ+bH8DI5LTfI BAlQD8JYYqI4z7OCymlTNf0aUK3T3BfdCo8gWjkT+KCEYVSEPHxNNFsIpmGpYn1noikQc8EXiAeY E96haS6DNs6o0H/tJ18nP+ZJG3zefrqunz68qDbbUg7GYiwTT77eKbeuUTkrbXy7tqw02ip4l7aR 1sdOlc5u1mtw+nNJx52y0rfQ0S+5qD6WUg7eHlyAxpd5Um1gsVenUk2H6Kf1yi2u16ttfXag4a+j d4edPHHQycuApiR2EwYHcZpw2nc1NB8auxn5ogOYhx7XCN73q9iE7Z4j/4wPdYtwOsGoD82L3AaC LGwhj/JPhR1EYsI1DW5wxlGeqbgFgCnPtDkfAE7KCZJmsG9SZ9Xns6R8td+9m+Vm1TBrdpxg2fee lfjsGazKFBZO+uFZHF3BVBY8bOVvnb/geApLFEOTFxU5PHMPFdqdtofKbW5O49zdlHK9af2HyAYQ LrqHBeGcNqFdv/TqLBbVdVenlA+SO2coUe0jooZFkte3ISI47twQSLeLiOhptyEiKpqiG9/8BXe+ jov/2Lvg/ziw44D8tuX/8Hv+z10cx+r/z4v/Cees6+s/Mj70ffzvLo4/Mv4nYD2HnG5BeFWEH6bx ipxY/xGOmDDGoziHVIEI/BH+mHLCdR0Ek3ZcuFA4HG6QRztmYDeR70M5sqRzBqsX5Go5RYiRDBtK xXH0lXo7OmgIr4dU4I4NGArFQxd9dcQyjYwWxthWJxbpKF+SjBZyi9bPhqpGRwuD4civOTZWKDmq Zqi4BOUkG+5RZEFQ45IMFAojfSdLQwSXyDihiFGUbkBTkQwqTAjyQRqnNEdGCQXXSqJggjw2SKgc oPvwTCBDhJHz1b0etSlABgiFtdygaX5kdFB6DEWUVMjQoNU4MHh0WNBwIQdfrayn8HJKGIHmOLm9 QkUSlZLSDr9ahlkcoxNK+641SQCKziire8teZboFvKJayzCrMc7qgKKBiphypoQgEcxqYxFceqKT RpZAEx4kKmBjRVTLIGswyFqHxxbVWsZYgzAW9IbCDZKIUJgMsQbvyRiFYEETkiwRzl5k1PIgB6vZ jLAWI6xSCNAlgSY2I6xFCCuNRaigqXhNRlircUjdoPCIp1rLCGvxXozyViJRkvGhDLHW4XCxt2pQ 4TZDLI6LgxFHUWZFaM5liHUIYpXnCGKpjRiXIdYhiJUaBsrg1HEZYJ3C44SjjVCyWsZXh7dgtEdb DJSj4TK+OosjMyGg0AwxB1zGVxyWBX8IBekopPQZXz3G12A9mt+EAnwGWI8AVnGJnVGqWgZYjwAW wBbBuSFGpc8A6xHAQhdt1xq1X+dL0BIBrAoOb/RSIilubM+P9b4bk5rQm88A6xHAGkCkbnBRrlDI ABvwFo/kePeBkGTZtwgIYLVXyHhTkgwZYAMC2PjBgMF7mIQdCBliQ9+N9dhaecI4Blfce4wowQm0 00HJM2SYDQhmlXa3GGPBM87mszTImvh+p0Bqf59nrIUlOHYAAqxi8IYr1V3BM5TBggTBBOgELWUk 5cAJkZECXOBOugGgFA1wqk2Zp6GQaIgbmBp+cIgLmce4UHgZ5ALarHdUV1VZBqne7p7EaqGWQbqo RSPT4rTDWxWUUnS2LOCwo+1zgF+E2tQCymTYFgZBojXqFv9dWF6WbBhvYCGLAJ9YZoATnIWD92vh DcWwayBcWZQ6NEvAN0Z7cpJq0ZXlnkd2HpxBqYZnic+GXgSOR45GDgIp1ZBtaN5MTMsbqZF0BLXL D0uzvFjkeLsCOmvwop1AO4DDbnmKtm5gYYZ2LDS5Qi2BAtlbgYNF5TgKQi0byxpc4uWtFxLNaMrM yW59i5eOYEKsG1SLLGtHiRdlFoy/H1SLLKsyiZc8UbJoBJEr8W4PCZk7KzTaiaZAS5YFhcTOupbY KpO6LN66xJ4wOPkWbV9Ty/HiCkvsZAIS8FtaLF6mxB6cENagNTIF6rL4cBL7Rw6GAx/ua3GQJHY+ DHj7aFVOcpPK/n7o7R46h3aBKRCRxbZLbDHBA8eapBg/xWLC6MOUPcfRKo+kJ/GMzUogbPYAIogt JilDokSJWhiEIxaaRCyGyBkh4hYZRzIZIu1gx29ZUFUCDDQvq2C8eBPWWY9Gn+YkiSeLyQgEmTBu PfLVBIUHRmTQhLHvkJz61BZLrYhtnp8WBywVLNzR0ooKPNoSsbS9NaAOEjmJnsA9W1aBTvQ4MQYw f9AeOdEtXvB8ie/ZvWigli+2Cx4jmAZHmCMOADUIfQl5eryIjKM6cBzvoVz9spAMskc9U1Z3VQ3F cS2uV8C2HtQrUaNUm6Ez9lz21vRC2GHMhQqFgcPxGtZw2wDOQIwEKnReZo8w6QCz0YAg3cUSCoVR h82+8Voh7pug2GRQpTP8OETmtIWZgeIYVJw/mv4MpRqbKCVh+ntMLaRAUXd8NN+bBjCyjbXDPZe+ WA4lcUQETJFVKHJGwpR0XaQUL1wVvIbGLk8g2ZS2rJzgPdHgBHBSHrnpgiLjAtDl99aqt5gBt9kh mCSHGfSweLLlPIcn9TAnJ+4tFhNmgkUagzVCkJjVTft64KGXMCBMRKxyzz1YE8w/p2iT4FeUqIaR wXLMgQQvAwSoEZApl7W3S5LpVkkSx1qbH1gCfyDPDfAjaqstKyUsz2CoHEHrAD/OxxROt/A6dood JnYMFdxlduyU/QyyG0Fd035odBHMNfQVwwGyU24FR8YUJrK2k+AILcpC5xFyWI+yUHO8cq1P8P+Z 6HS8YOJaN+ABDsgaVz27lXo8J9mRiLimyJzEbAgAgW1AYXA2oGLDs+FQQWo2oLL7RKej+R9/av6X wv9QxjX8D9DCPf/jLo7j8r8I2+iExU+6wJXoZ4Dx8dM9ZrzrZ4AxKn6nwyKL3O5ngFFgPGH2yX4G mPgZWFD7KWBiIhcbDBMGvGjPcQ4YcJUd/OPDbg4YpZSPOWCE17s5YGTOASP1NGd48U2Gk70cMGrq TVtCuqmhc8CUrC1yqjWdAyY07ezlgJFTqXdywKiUaqVJOiMO54ARZppzwED7VA4YMXW+5KbRh3LA iGNzwIByZMkBwwT3JQeMUtNwew4YWVqAJ6EcMCpMw3E5YOKOghjBIoyPdj8izzcF2P4ROzmLX8GC ChOrafJhtX6Xk57Ebynah2BOG093wVe17d3eU7ZRafgpzLownHQGlrZQQAYiYY2EahJmh9jPR8Og VkyINep9PJ+eOIqxyoNZXjSMxKG8MsLz4Yw06GP1fzcs3R93dHym/f9z8r9wW+w/rOjb/C/39v9O jlvyvwDMT+Ux+V+iDfis/C/mM/K/+JxoZTj/C4yao/K/8Jy+oS11TP4XbaZuN/+Lkjl1R5f/JToU u/lfVO59yf8Sk3uka738LyZnTklJXpo0OZZMCUPkfwGLs5d5pTWPXeqPw6ZRy5IUBtkkUR65mxKm JJfYtaIH8r9Ysgt9u6rzy9IJX1xOWrNvcEuujN1sMKXRz8sGo4gELgNpYg7mdrG/M7eLAOTMerkB iM4ZX7y4PZnLUWlhrNFZkXTeFlvUeThvS5BZYAN5W5zPwnsdDcwWxswSBsKhlC7e51lKpHSxLr/+ XiIaWCKUUTRbgr+cM6Lcng+Gu/yqRPIbAYrQw9liXJbkd9U/6p+hze1VllK8XcZoP5lMufyvJ5P5 He7acfbf3MX3PxZ8BKEkb77/Ue7++5+7OI7V/5/4/Y9WwvT1L2MCinv/7y6OP/L7H93jtIMOSeZ3 CrIjNpxpuFR5/4liBdBMYGEDylkhHLV7TDGBXdACf2BO1aOowJZbhRjL1JYzRQUGO4wICIKi2pBc YKcDYlwJfiwZ2AmNNvIDxVimyMAmaEQHceS2OEEG1l4jZrslM0wQZGBtFdo2pCgDJBk47kprJEzq 4w6SDuwsJswFQpYkHVgILeQthAqSEBycVXhvkeonxQgW3BiFc6JQDGSKEywANdE+oiD51RQr2HuP vsei6BAkKzhY5/DeJ0UuoGjBTmJWHzVnaVqwVC7gWUTsx5G04LjFgzfmPcUnJmnBoAn8ZQ9FyiNp wcIaj4iAgsyjRRODhfEap3OgyNaHiMHWeo74z8KSHyrSxGClHf7cTZGMSZoYLIPBPG9J0mZparBU XCDeLMmvOkAOls7w274COUAPluBpoA4LR7VKE4Shatz+7kRMsWBpirC02uOdekdpliYJSwABvBFN fSx2gCYsTeilg6NSTx0gCiuuFLJ25Lw5QBWWDmwxIr9Rmd0OkIXB/ZO3KoemC0vle0wU6iOrA4Rh JaTBGVEo7tshwjAYFoudHoq6SxOGPagbjWFNpqOjCcOag/1EYiL5QjRhOEZbEfEXcPVoyrC00F80 mijH6QBpOCa/Qp9eC4qVf4A2LIPA30SRFvEAcVjBcxD3nG6Vpg4r0JQTt4iJJg9HohZyicjPXQ/Q hwGnHM6XQyYMpAnECrqPUYLMwkgziBUHkEWtcpIKTHKIZdyYxcx1ivZGs4hVkAp/dkNS0GkasQY0 wh2mvjk8QCRWupVfUQ7FdqOZxC5yZxCTmBpNB5jEkTdlHEqcRdG0D1CJwU+2Hg1FTw3FA1xiGVT8 X7Z07jmF4ge4xCrmPcDpMilO+gEycdzbNK5zniy1FDzIJtYh/F97Z7PbNgzD8XP2FD4XaKAPipIf JyiCtSjaFW0P29uPciKZsinbWZsO2MRjIieOLYmk8yP/HCeWSv4qPLENtGQYYe6k7KdCFNsA2DN4 X+xkyZlitgzAGR9YTSRKa55TxbywJuigWWcDVGKJo8gV0+IDZPkQStO5xhXbeI94DiaF/jJZ7Gij QjafndQ0osYWowmW14ShWNpT0MVsn8OYkTFO10l1flW+mMILR1eBt7sQY6IaY0we0FrN2tMBSs8B SsqY11xQUg+KpRVWDCLpoLxnQuGW4gkUaQlKIRIdlJ1/KPpTIMW+DJuXfGkIY9u/gpDu0fACHhEz zlm7LRZmZH14M2TpOUHR/5J7inhGvFBZIpQZY4wOuEt1tMfz2pE4M4QHTDmA7hPxe847e7CueMwk ztbUgnXwvAVgTdkn8nJpkXE2Y6sUigz47hA3JVYYJDaRxriWUzhRxJiewmzHqgfE8JQS6+x5el+0 4hyIX17/Lj3fcRRLp11C+Z6neDELNZolPunXT6hYqbn39bhmS9tXpjhtiCmsPyUpy1gsGeWOcHKi dTQ2dmUB5+xav7rJ5y0jsuXYj/XwDCuVMwIJrXlDCWmvP89ePX6L5g+DN95Bm3FzHXfpZXg3DaXp 1wts7b8FNV9yZeL8tuP8pu1PefCfSzXHCal7h7BySWkxQOyFscb4Tz5vdTGwsf9x+8YP2+b//67J fzud//+jyOWk/4nt/7+vsI38t3KObk4H5DlQTQRAKUbwXZjIfzrQgFGSCswc/qa0jDYZC3qi/0lT TYC/DWUetN47g32wmrPflNl0GryfyX9aSmnppMHM5D8hy39i4qz9HnxF/lOdRqi9rch/DuRzHNJ5 X0DYGf2m8+ll+U8IE/TbqL1PILnCOvqN+6DO6LcumfRR/hPgNKKj1Oyxgn7bzeg35UAj+k0B6ij/ qbag3zDKf4aBVT+j38ZuRb+jC1M79MHskrZZNA3W7owxuJururMRNN92AuYVjVLLHcX4YU5iU367 DHjHo+LzRQHwpt3tBJHfvN29Ht7v7kfYOn5fFBPtbt4fXiaAtl4CtE3P3jSb1T2raqLWr+mFFojb 396oml3FLvT/V+G/0TL/b+zAf5vG/3yJrfDftNfv1Sb9T5NY13Wee2CHL2DFO0wM+or+Z68S+vnJ /LcbxPgm/Lcx6TWm/4lJqnRJ/9Mrl0604L9rsPdwCUo0XNL/9JmKTT6y1wkelvwjuMxAM+dnszbp 3GXqTEYXjq1P4OvUe2Fitqeeq8prZ2HSuc81I5WdXOeC2ufFDHcnynlWyW73Jaqd3mUAf0Y6x7W5 CoG7Xi3y3WBDIYL5evx+/Hl7f3i7/9ZZnQVh6+y3xG47lZVb6e7dHV5unx7oqOPP9+NzpAzflihs 49IkEMBvlc/o1+H58fbp+DxM81w48PhAv28Is4f3X34M8a48JL6aBUdLJju//CGBzywT+gcCny3e atasWbNmzZo1a9asWbNmzZo1a/YZ9ht+tEEpAKAAAA== ----Next_Part(Tue_Jul_20_12_43_31_2021_790)---- From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 20 07:43:59 2021 Received: (at 49656) by debbugs.gnu.org; 20 Jul 2021 11:43:59 +0000 Received: from localhost ([127.0.0.1]:32993 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5oAJ-0008Cu-2t for submit@debbugs.gnu.org; Tue, 20 Jul 2021 07:43:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38856) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5oAG-0008Ch-Nu for 49656@debbugs.gnu.org; Tue, 20 Jul 2021 07:43:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41002) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5oAB-0001Jy-5K; Tue, 20 Jul 2021 07:43:51 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3420 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5oAA-0002Bx-MJ; Tue, 20 Jul 2021 07:43:51 -0400 Date: Tue, 20 Jul 2021 14:43:46 +0300 Message-Id: <83o8ax5hxp.fsf@gnu.org> From: Eli Zaretskii To: Madhu In-Reply-To: <20210720.124331.173592885202931943.enometh@meer.net> (message from Madhu on Tue, 20 Jul 2021 12:43:31 +0530 (IST)) Subject: Re: bug#49656: more data on #43389 References: <20210720.124331.173592885202931943.enometh@meer.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49656 Cc: 49656@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 20 Jul 2021 12:43:31 +0530 (IST) > From: Madhu > > This is the emacs memory bloat issue. I thought I had unarchived the > bug earlier but it seems to be closed up again. Should I open a new > bug? Its already got a 1000 posts on the bugzilla page I'm not yet sure this is a bug, FWIW. > Over the past few months, I've experienced the memory problem a few > times. I wanted to share the malloc info data I collected on 3 > instance and am attaching a tarball with 3 directories named 4 5 6 > which include malloc-info, memory-usage, and memory-report data from > emacs exhibiting the behaviour - after all buffers are killed and > after an M-x gc. > > Directories 4 and 6 show the common pattern where memory is used > unknown to GC. data in directory 5 probably another issue where there > are a lot of dead strings. I've looked at the data, thanks. But the most important information is missing from the data you presented. The case where you have 570MB in strings could be interesting, but without knowing what you did in that session, it is impossible to say whether there's an issue there. It could be explained by the live Lisp data you produced in that session. So what we need is the following, for each case separately: . the size of the memory footprint of the Emacs session . how long was the Emacs session running since it started . what were the main activities in that session . do you have some customizations related to GC, and if you do, what are they . what Emacs version is that, and what are its configuration parameters and features compiled into it In general, that old bug is closed, because after making a single change that did cause memory bloat in some usage patterns, we concluded that the rest were user problems caused by messing with GC thresholds. The glibc developers looked at the data we collected and found nothing that could be interpreted as a bug in glibc. TIA From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 20 07:56:29 2021 Received: (at 49656) by debbugs.gnu.org; 20 Jul 2021 11:56:29 +0000 Received: from localhost ([127.0.0.1]:33063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5oMP-0002Ju-30 for submit@debbugs.gnu.org; Tue, 20 Jul 2021 07:56:29 -0400 Received: from quimby.gnus.org ([95.216.78.240]:56536) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5oMM-0002Jf-Lh for 49656@debbugs.gnu.org; Tue, 20 Jul 2021 07:56:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=qQ4Fnhcmmgy3lXpYEa8o06Qg2DoyE9N18+WKKPhZ38E=; b=Qm0F05jQ7qDPdGI2cAQfe5PF+q PyNzFMzAtMTAn42B1O3SR4HePMxExulvZhhYxxSh7WVb0MFE1lOAVjZAO7VSybz5nZKzOtgf+sV2e ILWBfT4rRcxzmV6rBIUlrb0ySWGe4qxbsOTilMWM7vp90z0BcObPV/xuIo7wDK/IHUyI=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m5oMD-0002nb-R6; Tue, 20 Jul 2021 13:56:20 +0200 From: Lars Ingebrigtsen To: Madhu Subject: Re: bug#49656: more data on #43389 References: <20210720.124331.173592885202931943.enometh@meer.net> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAALVBMVEUFBAsPESopFRpd FB/PKzbVXp1JT0PdtUy7vMOUDhpBiiEhJFk/XKJckM/////cWtUyAAAAAWJLR0QOb70wTwAAAAd0 SU1FB+UHFAsyK6qffpkAAAFRSURBVDjLY2CAAAEG+gEmYyVlBWwSLKEhoQ7YJFSAEk5YzElgS04z NoByGYGeYAKz2CrawLQgQi0jVKIMrLHcGc0otrQkMFXuiSLcXgGzaoonsjkM7eWwANNENarchQGL hKYlzJEMSgxKSkgeczFggASFiQtKkIAkIFZMmYmQYFJSYALqFgC7QokRoZzTBRQ8TDNBwADZHLCE ANMEJSVNYyQJJSUmMJcJSDApCiAkVq2C2pSAFkIEJTCS0LZEKEMBTWL3bqhRBgw4gLERugh3Nshe prQ0QSAQQIpYnt6LoGi5c/YMEN65i+QIQQFpaRj3zA0U1+09cQDmljM4JBjgcQ0G0jIbEOwbG5D1 MOyIhkl0oAbOjmCYxF1UHfCwYhRCDzWYxG50CcaNG8GUIKbSjbjCkYFRgBG7BYyCikIK2CTE0tLS ErBJCCoJauNwLB0BAObeQfYY7VR9AAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIxLTA3LTIwVDExOjUw OjQzKzAwOjAwAdqZaAAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMS0wNy0yMFQxMTo1MDo0MyswMDow MHCHIdQAAAAASUVORK5CYII= X-Now-Playing: Squarepusher's _Be Up A Hello_: "Nervelevers" Date: Tue, 20 Jul 2021 13:56:17 +0200 In-Reply-To: <20210720.124331.173592885202931943.enometh@meer.net> (Madhu's message of "Tue, 20 Jul 2021 12:43:31 +0530 (IST)") Message-ID: <87fsw9gpwe.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Madhu writes: > This is the emacs memory bloat issue. I thought I had unarchived the > bug earlier but it seems to be closed up again. Unarchiving a bug doesn't reopen it -- you have to do both. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49656 Cc: 49656@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Madhu writes: > This is the emacs memory bloat issue. I thought I had unarchived the > bug earlier but it seems to be closed up again. Unarchiving a bug doesn't reopen it -- you have to do both. > Should I open a new bug? Its already got a 1000 posts on the bugzilla > page You did open a new bug report. :-) bug#49656. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 20 12:08:46 2021 Received: (at 49656) by debbugs.gnu.org; 20 Jul 2021 16:08:46 +0000 Received: from localhost ([127.0.0.1]:35160 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5sIY-0001qf-Ck for submit@debbugs.gnu.org; Tue, 20 Jul 2021 12:08:46 -0400 Received: from smtp6.ctinetworks.com ([205.166.61.199]:34882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5sIW-0001qW-00 for 49656@debbugs.gnu.org; Tue, 20 Jul 2021 12:08:44 -0400 Received: from localhost (unknown [117.193.15.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: enometh@meer.net) by smtp6.ctinetworks.com (Postfix) with ESMTPSA id D9F1485942; Tue, 20 Jul 2021 12:08:39 -0400 (EDT) Date: Tue, 20 Jul 2021 21:38:37 +0530 (IST) Message-Id: <20210720.213837.660237047276474473.enometh@meer.net> To: eliz@gnu.org Subject: Re: bug#49656: more data on #43389 From: Madhu In-Reply-To: <83o8ax5hxp.fsf@gnu.org> References: <20210720.124331.173592885202931943.enometh@meer.net> <83o8ax5hxp.fsf@gnu.org> X-Mailer: Mew version 6.8 on Emacs 28.0.50 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ctinetworks-Information: Please contact the ISP for more information X-ctinetworks-MailScanner-ID: D9F1485942.A89E1 X-ctinetworks-VirusCheck: Found to be clean X-ctinetworks-SpamCheck: X-ctinetworks-Watermark: 1627661323.30683@6w+5Ep33KYPJT9Z/5YPXdQ X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49656 Cc: 49656@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * Eli Zaretskii <83o8ax5hxp.fsf@gnu.org> Wrote on Tue, 20 Jul 2021 14:43:46 +0300 >> This is the emacs memory bloat issue. I thought I had unarchived the >> bug earlier but it seems to be closed up again. Should I open a new >> bug? Its already got a 1000 posts on the bugzilla page > I'm not yet sure this is a bug, FWIW. It's been bugging me for a few years now, but I won't mind if you close it. >> Over the past few months, I've experienced the memory problem a few >> times. I wanted to share the malloc info data I collected on 3 >> instance and am attaching a tarball with 3 directories named 4 5 6 >> which include malloc-info, memory-usage, and memory-report data from >> emacs exhibiting the behaviour - after all buffers are killed and >> after an M-x gc. >> Directories 4 and 6 show the common pattern where memory is used >> unknown to GC. data in directory 5 probably another issue where there >> are a lot of dead strings. > I've looked at the data, thanks. But the most important information > is missing from the data you presented. The case where you have 570MB > in strings could be interesting, but without knowing what you did in > that session, it is impossible to say whether there's an issue there. > It could be explained by the live Lisp data you produced in that > session. That 570MB case was the exceptional case - i noticed that only once. In all other cases I hit the memory leak gc thinks it only has 200M while the process has 1.5 to 3.5 GB resident. I don't see how this can be a user error. > So what we need is the following, for each case separately: > . the size of the memory footprint of the Emacs session I have this data for a few runs. The sizes from `ps' correspond exactly to what malloc info shows so i decided to omit it. > . how long was the Emacs session running since it started 2-3 days usually. I always have to kill emacs because I cant suspend the OS to disk because all of it is resident. > . what were the main activities in that session . do you have some > customizations related to GC, and if you do, what are they . what > Emacs version is that, and what are its configuration parameters > and features compiled into it I am not doing anything special with GC. All the recent reports are on Emacs 28, within a month of two of master. The problem is independent of the toolkit, I get it in motif, gtk, and xt. I havent tried a no-x build in 2 years. if you remember I asked on emacs-help once and you informed me of a GC fix and it fixed that problem. > In general, that old bug is closed, because after making a single > change that did cause memory bloat in some usage patterns, we > concluded that the rest were user problems caused by messing with GC > thresholds. The glibc developers looked at the data we collected > and found nothing that could be interpreted as a bug in glibc. But doesn't the malloc info allocation and the gc reports indicate a clear discrepancy? Does it not indicate a leak which the GC is not aware of? From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 20 13:11:43 2021 Received: (at 49656) by debbugs.gnu.org; 20 Jul 2021 17:11:43 +0000 Received: from localhost ([127.0.0.1]:35235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5tHS-0003Mv-PH for submit@debbugs.gnu.org; Tue, 20 Jul 2021 13:11:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53218) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5tHQ-0003Mi-Dg for 49656@debbugs.gnu.org; Tue, 20 Jul 2021 13:11:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52114) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5tHK-0006jR-SN; Tue, 20 Jul 2021 13:11:34 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3736 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5tHK-0004PT-Ft; Tue, 20 Jul 2021 13:11:34 -0400 Date: Tue, 20 Jul 2021 20:11:29 +0300 Message-Id: <837dhk6hby.fsf@gnu.org> From: Eli Zaretskii To: Madhu In-Reply-To: <20210720.213837.660237047276474473.enometh@meer.net> (message from Madhu on Tue, 20 Jul 2021 21:38:37 +0530 (IST)) Subject: Re: bug#49656: more data on #43389 References: <20210720.124331.173592885202931943.enometh@meer.net> <83o8ax5hxp.fsf@gnu.org> <20210720.213837.660237047276474473.enometh@meer.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49656 Cc: 49656@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 20 Jul 2021 21:38:37 +0530 (IST) > Cc: 49656@debbugs.gnu.org > From: Madhu > > In all other cases I hit the memory leak gc thinks it only has 200M > while the process has 1.5 to 3.5 GB resident. > > I don't see how this can be a user error. It could be if, for example, you are using packages or your own code which plays with GC thresholds. E.g., I'm told that lsp-mode does that; are you per chance using it? > > So what we need is the following, for each case separately: > > . the size of the memory footprint of the Emacs session > > I have this data for a few runs. The sizes from `ps' correspond > exactly to what malloc info shows so i decided to omit it. Ah, but gleaning this from the malloc info takes some time, so telling the number explicitly will help making the report more easily understandable. > > . how long was the Emacs session running since it started > > 2-3 days usually. I always have to kill emacs because I cant suspend > the OS to disk because all of it is resident. How much memory and swap do you have there? Can you enlarge the total VM size (by enlarging swap) so that you could run Emacs longer when it gets to such large sizes? Btw, 1.5GB is not too large for several days worth of work. > > . what were the main activities in that session . do you have some > > customizations related to GC, and if you do, what are they . what > > Emacs version is that, and what are its configuration parameters > > and features compiled into it > > I am not doing anything special with GC. Are you sure no package you use does something like that? What were the values of GC thresholds when the memory was large? Was the value of gcs-done increasing with time, or did it stay put (which would be an evidence that Emacs doesn't run GC at all)? If GC was running, how frequently did it run? (You could answer the last question either by looking at the rate of growth in gcs-done, or by setting garbage-collection-messages non-nil, which will cause Emacs announce ever GC in the echo area.) > if you remember I asked on emacs-help once and you informed me of a GC > fix and it fixed that problem. But that problem was fixed, so it cannot possibly affect you now. And we found that problem because the user reported lack of GC cycles after some point. > But doesn't the malloc info allocation and the gc reports indicate a > clear discrepancy? Not to me, it doesn't. It means the malloc arena holds to a lot of memory that it cannot release to the OS, but it is known that this can happen for certain patterns of memory allocation and deallocation. You can find explanations of why this happens on the net. > Does it not indicate a leak which the GC is not aware of? No. Emacs allocates a lot of memory for purposes other than Lisp objects, and that memory is not visible to GC nor to memory-report. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 20 21:46:32 2021 Received: (at 49656) by debbugs.gnu.org; 21 Jul 2021 01:46:32 +0000 Received: from localhost ([127.0.0.1]:35810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m61Jg-0001C1-14 for submit@debbugs.gnu.org; Tue, 20 Jul 2021 21:46:32 -0400 Received: from smtp6.ctinetworks.com ([205.166.61.199]:52838) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m61Je-0001Bt-I1 for 49656@debbugs.gnu.org; Tue, 20 Jul 2021 21:46:30 -0400 Received: from localhost (unknown [117.193.14.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: enometh@meer.net) by smtp6.ctinetworks.com (Postfix) with ESMTPSA id 297AA8437C; Tue, 20 Jul 2021 21:46:25 -0400 (EDT) Date: Wed, 21 Jul 2021 07:16:23 +0530 (IST) Message-Id: <20210721.071623.1810463348128672347.enometh@meer.net> To: eliz@gnu.org Subject: Re: bug#49656: more data on #43389 From: Madhu In-Reply-To: <837dhk6hby.fsf@gnu.org> References: <83o8ax5hxp.fsf@gnu.org> <20210720.213837.660237047276474473.enometh@meer.net> <837dhk6hby.fsf@gnu.org> X-Mailer: Mew version 6.8 on Emacs 28.0.50 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ctinetworks-Information: Please contact the ISP for more information X-ctinetworks-MailScanner-ID: 297AA8437C.A97A9 X-ctinetworks-VirusCheck: Found to be clean X-ctinetworks-SpamCheck: X-ctinetworks-Watermark: 1627695989.78771@V1HIfygic/82UQkRFPL3DQ X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: * Eli Zaretskii <837dhk6hby.fsf@gnu.org> Wrote on Tue, 20 Jul 2021 20:11:29 +0300 >> Date: Tue, 20 Jul 2021 21:38:37 +0530 (IST) >> From: Madhu >> >> In all other cas [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [117.193.14.230 listed in dnsbl.sorbs.net] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record X-Debbugs-Envelope-To: 49656 Cc: 49656@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) * Eli Zaretskii <837dhk6hby.fsf@gnu.org> Wrote on Tue, 20 Jul 2021 20:11:29 +0300 >> Date: Tue, 20 Jul 2021 21:38:37 +0530 (IST) >> From: Madhu >> >> In all other cases I hit the memory leak gc thinks it only has 200M >> while the process has 1.5 to 3.5 GB resident. >> >> I don't see how this can be a user error. > > It could be if, for example, you are using packages or your own code > which plays with GC thresholds. E.g., I'm told that lsp-mode does > that; are you per chance using it? No I haven't gotten around to trying that i'm sure none of my packages mess with gc-threshold. I will double check that. > How much memory and swap do you have there? Can you enlarge the total > VM size (by enlarging swap) so that you could run Emacs longer when it > gets to such large sizes? The problem is not that emacs won't run. I am unable to use the memory in the machine for other purposes and am obliged to kill emacs. > Btw, 1.5GB is not too large for several days worth of work. I also have emacs running for several weeks when the problem doesn't happen with RES never above say 500M for the same workloads and usage patterns. > Are you sure no package you use does something like that? What were > the values of GC thresholds when the memory was large? Yes I do not run a lot of packages and certainly nothing that I don't audit first - I am aware of all the packages that are loaded at least in the exceptional cases. There is no reason for me to suspect those packages because I use them all the time in emacs sessions where the problem does not manifest. > Was the value of gcs-done increasing with time, or did it stay put > (which would be an evidence that Emacs doesn't run GC at all)? If > GC was running, how frequently did it run? (You could answer the > last question either by looking at the rate of growth in gcs-done, > or by setting garbage-collection-messages non-nil, which will cause > Emacs announce ever GC in the echo area.) There is nothing exceptional with GC. GC usually completes quickly because it doesnt access much memory. >> But doesn't the malloc info allocation and the gc reports indicate a >> clear discrepancy? > > Not to me, it doesn't. It means the malloc arena holds to a lot of > memory that it cannot release to the OS, but it is known that this can > happen for certain patterns of memory allocation and deallocation. > You can find explanations of why this happens on the net. But that is the point - I've been asking from the first time I posted on this - WHAT is emacs allocating in these exceptional cases. I understand my usage patterns over the years of constant emacs use and the "random" memory bloat in some sessions makes no sense and it only suggests a memory leak in emacs code. >> Does it not indicate a leak which the GC is not aware of? > > No. Emacs allocates a lot of memory for purposes other than Lisp > objects, and that memory is not visible to GC nor to memory-report. This is too vague. This 2GB active memory is not legitimate and the point is to figure out where and why emacs is holding on to this memory. This is where I need assistance. my usage patterns are pretty deterministic The memory usage of the qlisp packages I use would show up in GC. SO what could that be, which it is NOT allocating under identical usage patterns? It isn't fonts or external images or anything else I can see. I'm sure others should be hitting the problem too From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 21 07:21:10 2021 Received: (at control) by debbugs.gnu.org; 21 Jul 2021 11:21:10 +0000 Received: from localhost ([127.0.0.1]:36262 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m6AHm-0005Ay-Ct for submit@debbugs.gnu.org; Wed, 21 Jul 2021 07:21:10 -0400 Received: from quimby.gnus.org ([95.216.78.240]:41376) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m6AHk-0005Aj-AH for control@debbugs.gnu.org; Wed, 21 Jul 2021 07:21:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=xuVmLtG9e2tOUf0LNB5WO24we8LNBx1HEevv46zixMc=; b=UfmO59Wbg4ydsQXnErnUiL6scO LjnOrRiKgLk5qNgX4SZCUiQm2FwPSLkP9z8wJh6CUINGoYtfiBxmBBBxOj3ux+Dm469OU2PX2Kgfg zP3j3bAGnfYXkYhYje+FVdNKsX8CIaD/kmh1uJvk8qsM8QkRH8tY52v+sYINNscpcM3I=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m6AHc-0005rX-O5 for control@debbugs.gnu.org; Wed, 21 Jul 2021 13:21:02 +0200 Date: Wed, 21 Jul 2021 13:21:00 +0200 Message-Id: <87mtqflxpf.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #49656 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: retitle 49656 Abnormal Emacs memory usage (bug#43389) quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) retitle 49656 Abnormal Emacs memory usage (bug#43389) quit From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 21 08:21:50 2021 Received: (at 49656) by debbugs.gnu.org; 21 Jul 2021 12:21:50 +0000 Received: from localhost ([127.0.0.1]:36380 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m6BEU-0004sO-5r for submit@debbugs.gnu.org; Wed, 21 Jul 2021 08:21:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m6BES-0004sA-5n for 49656@debbugs.gnu.org; Wed, 21 Jul 2021 08:21:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46014) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m6BEM-0004R0-Dj; Wed, 21 Jul 2021 08:21:42 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2273 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m6BEM-00087z-1q; Wed, 21 Jul 2021 08:21:42 -0400 Date: Wed, 21 Jul 2021 15:21:40 +0300 Message-Id: <83y29z502z.fsf@gnu.org> From: Eli Zaretskii To: Madhu In-Reply-To: <20210721.071623.1810463348128672347.enometh@meer.net> (message from Madhu on Wed, 21 Jul 2021 07:16:23 +0530 (IST)) Subject: Re: bug#49656: more data on #43389 References: <83o8ax5hxp.fsf@gnu.org> <20210720.213837.660237047276474473.enometh@meer.net> <837dhk6hby.fsf@gnu.org> <20210721.071623.1810463348128672347.enometh@meer.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49656 Cc: 49656@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 21 Jul 2021 07:16:23 +0530 (IST) > Cc: 49656@debbugs.gnu.org > From: Madhu > > > It could be if, for example, you are using packages or your own code > > which plays with GC thresholds. E.g., I'm told that lsp-mode does > > that; are you per chance using it? > > No I haven't gotten around to trying that i'm sure none of my packages > mess with gc-threshold. I will double check that. Thanks, please do. It's important to know that. > > How much memory and swap do you have there? Can you enlarge the total > > VM size (by enlarging swap) so that you could run Emacs longer when it > > gets to such large sizes? > > The problem is not that emacs won't run. I am unable to use the > memory in the machine for other purposes and am obliged to kill emacs. If you enlarge the swap space, your system will still be workable even when Emacs has such a large footprint. That's the purpose of my suggestion. It is important to have a usable system when these situations happen because if we come up with some experiments to conduct in such cases, you need a usable system to be able to do that. > > Btw, 1.5GB is not too large for several days worth of work. > > I also have emacs running for several weeks when the problem doesn't > happen with RES never above say 500M for the same workloads and usage > patterns. Then one thing to try to figure out is what was the difference between these two classes of sessions -- what and how did you do differently in one that you didn't in the other? That could point us in the right direction. > > Was the value of gcs-done increasing with time, or did it stay put > > (which would be an evidence that Emacs doesn't run GC at all)? If > > GC was running, how frequently did it run? (You could answer the > > last question either by looking at the rate of growth in gcs-done, > > or by setting garbage-collection-messages non-nil, which will cause > > Emacs announce ever GC in the echo area.) > > There is nothing exceptional with GC. GC usually completes quickly > because it doesnt access much memory. I'd like quantitative measures, please: what is the rate of GC cycles when the memory footprint is measurd in GBs, and how much time does each GC cycle take? Also, does the memory footprint becomes smaller after a GC cycle, and by how much? > >> But doesn't the malloc info allocation and the gc reports indicate a > >> clear discrepancy? > > > > Not to me, it doesn't. It means the malloc arena holds to a lot of > > memory that it cannot release to the OS, but it is known that this can > > happen for certain patterns of memory allocation and deallocation. > > You can find explanations of why this happens on the net. > > But that is the point - I've been asking from the first time I posted > on this - WHAT is emacs allocating in these exceptional cases. It's impractical to try to answer these questions. If you put a breakpoint on 'malloc' and 'free' and then run Emacs, you will see that it calls these functions extremely frequently, with widely different block sizes. We don't have infrastructure that would record each allocation and deallocation with enough info to be able to analyze that, and even if we did, finding the callers which are responsible for the memory that's not returned to the OS is a very large and hard job. We tried that previously, with the help of the glibc developers using their debugging features -- it didn't really help us with the diagnostics. > I understand my usage patterns over the years of constant emacs use > and the "random" memory bloat in some sessions makes no sense and it > only suggests a memory leak in emacs code. It is impossible to look for memory leaks in Emacs without some clues about where those leaks could be. If you can provide the information I asked above, we might be able to come up with such clues. Alternatively, you could try running Emacs under Valgrind (see instructions in etc/DEBUG), although this will probably catch memory leaks only on the C level, not on the Lisp level. > >> Does it not indicate a leak which the GC is not aware of? > > > > No. Emacs allocates a lot of memory for purposes other than Lisp > > objects, and that memory is not visible to GC nor to memory-report. > > This is too vague. But that's all I can say, given the information you provided till now. > This 2GB active memory is not legitimate and the point is to figure > out where and why emacs is holding on to this memory. > > This is where I need assistance. This is me assisting you. I'm asking you to help us analyze this problem by providing more information. I don't think we will be able to make progress here without that additional info. > SO what could that be, which it is NOT allocating under identical > usage patterns? I don't know, sorry. > I'm sure others should be hitting the problem too We could, of course, wait for others to report similar problems, and then hope the information they provide would point us to the right direction. IME, though, this is not a very efficient method, because in many cases the reasons for the memory growth are not the same. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 21 14:06:59 2022 Received: (at 49656) by debbugs.gnu.org; 21 Aug 2022 18:07:00 +0000 Received: from localhost ([127.0.0.1]:36713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPpLf-0008KD-LQ for submit@debbugs.gnu.org; Sun, 21 Aug 2022 14:06:59 -0400 Received: from quimby.gnus.org ([95.216.78.240]:44950) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPpLd-0008Js-Gn for 49656@debbugs.gnu.org; Sun, 21 Aug 2022 14:06:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=E5i9H3XeiKknTt82nS+vPVZufQ2Ha3quZiZ8BhNlw5w=; b=OFPjLvO5Z/20mjJvILVmPfbR8P sW7rQ75E7/BKqgEGahyrfi3WHay/B4nR79AXIQS125fgpKZQB3+rZXGEafbDTjEoM43vPSM6qb07p jLdLzvCrBIJ5Mjgqi66qu0lJsbVrCVPgDAvmFX7TfaXzMV4IuDRt5ZpFuffZR7ajro3k=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oPpLU-0004ey-IA; Sun, 21 Aug 2022 20:06:50 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49656: Abnormal Emacs memory usage (bug#43389) In-Reply-To: <83y29z502z.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 21 Jul 2021 15:21:40 +0300") References: <83o8ax5hxp.fsf@gnu.org> <20210720.213837.660237047276474473.enometh@meer.net> <837dhk6hby.fsf@gnu.org> <20210721.071623.1810463348128672347.enometh@meer.net> <83y29z502z.fsf@gnu.org> X-Now-Playing: The Style Council's _The Complete Adventures (3)_: "Our Favourite Shop" Date: Sun, 21 Aug 2022 20:06:46 +0200 Message-ID: <871qt9bhe1.fsf_-_@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> No I haven't gotten around to trying that i'm sure none of my packages >> mess with gc-threshold. I will double check that. > > Thanks, please do. It's important to know that. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49656 Cc: Madhu , 49656@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> No I haven't gotten around to trying that i'm sure none of my packages >> mess with gc-threshold. I will double check that. > > Thanks, please do. It's important to know that. (I'm going through old bug reports that unfortunately weren't resolved at the time.) This was a year ago -- Madhu, did you make any progress in identifying the problem (if you're still seeing it)? From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 21 14:07:04 2022 Received: (at control) by debbugs.gnu.org; 21 Aug 2022 18:07:04 +0000 Received: from localhost ([127.0.0.1]:36717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPpLj-0008L1-VB for submit@debbugs.gnu.org; Sun, 21 Aug 2022 14:07:04 -0400 Received: from quimby.gnus.org ([95.216.78.240]:44966) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPpLg-0008K1-OD for control@debbugs.gnu.org; Sun, 21 Aug 2022 14:07:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=sMDjupWY7/acX1c1fl9W3uLAWcFS2pDLA6RlDu53y4Y=; b=RURdEEqaClSb/UmXb2mK8BfYA+ Kt5EYHyJfqmr+AHDVp9G/ZGebIvbxtiCAz578TAT7fGvUOgFaUMhl/AOK7jKYaA2HA3GJ5YhAQtmg JZ78Qax5JC6KNad2LpYxP/+/u6HMBY3ugV3Sze7MejSRMTih17jUqNN/hCZwnnrDLqxA=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oPpLZ-0004f5-9B for control@debbugs.gnu.org; Sun, 21 Aug 2022 20:06:55 +0200 Date: Sun, 21 Aug 2022 20:06:52 +0200 Message-Id: <87zgfxa2tf.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #49656 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 49656 + moreinfo quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) tags 49656 + moreinfo quit From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 21 22:07:38 2022 Received: (at 49656) by debbugs.gnu.org; 22 Aug 2022 02:07:38 +0000 Received: from localhost ([127.0.0.1]:37209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPwqk-0008KR-O6 for submit@debbugs.gnu.org; Sun, 21 Aug 2022 22:07:38 -0400 Received: from smtp6.ctinetworks.com ([205.166.61.199]:38516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPwqf-0008KH-IN for 49656@debbugs.gnu.org; Sun, 21 Aug 2022 22:07:33 -0400 Received: from localhost (unknown [117.193.2.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: enometh@meer.net) by smtp6.ctinetworks.com (Postfix) with ESMTPSA id 7B9FF85B86; Sun, 21 Aug 2022 22:07:26 -0400 (EDT) Date: Mon, 22 Aug 2022 07:37:10 +0530 (IST) Message-Id: <20220822.073710.273511389537406275.enometh@meer.net> To: larsi@gnus.org Subject: Re: bug#49656: Abnormal Emacs memory usage (bug#43389) From: Madhu In-Reply-To: <871qt9bhe1.fsf_-_@gnus.org> References: <20210721.071623.1810463348128672347.enometh@meer.net> <83y29z502z.fsf@gnu.org> <871qt9bhe1.fsf_-_@gnus.org> X-Mailer: Mew version 6.8 on Emacs 29.0.50 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ctinetworks-Information: Please contact the ISP for more information X-ctinetworks-MailScanner-ID: 7B9FF85B86.A8532 X-ctinetworks-VirusCheck: Found to be clean X-ctinetworks-SpamCheck: X-ctinetworks-Watermark: 1661998048.1908@FECpBAwTm9VnYgjCZbBYmg X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49656 Cc: eliz@gnu.org, 49656@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * Lars Ingebrigtsen <871qt9bhe1.fsf_-_@gnus.org> Wrote on Sun, 21 Aug 2022 20:06:46 +0200 > Eli Zaretskii writes: >>> No I haven't gotten around to trying that i'm sure none of my packages >>> mess with gc-threshold. I will double check that. >> >> Thanks, please do. It's important to know that. > > (I'm going through old bug reports that unfortunately weren't resolved > at the time.) > > This was a year ago -- Madhu, did you make any progress in identifying > the problem (if you're still seeing it)? No, I haven't triggered this problem recently with emacs-29. Maybe I've stopped using the packages that triggered it. The bug should be probably closed, Thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 22 06:06:36 2022 Received: (at 49656) by debbugs.gnu.org; 22 Aug 2022 10:06:36 +0000 Received: from localhost ([127.0.0.1]:37932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQ4KK-0006Ml-0k for submit@debbugs.gnu.org; Mon, 22 Aug 2022 06:06:36 -0400 Received: from quimby.gnus.org ([95.216.78.240]:52292) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQ4KD-0006MO-CS for 49656@debbugs.gnu.org; Mon, 22 Aug 2022 06:06:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=receiy3cODHZSLUpvvCKf8PkQ+z4B+Ng05lHyQiJ3w8=; b=FsJwI8Jj+AZRI6EXAkqxJDZlVM C2qSVD31UwuualtwEZ2aMOi4q00sRjMxnc94Ike8BwGBWm7b2YIKF5ThUo8jcJS55P9seFt0am1S6 gFV3jaVGDUW5LJMglo3n277b7C4/qcj9+oWa3y1dAEENnRX2GBXoGtnWjRv55jVFJgIQ=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oQ4K3-0004Fw-3Y; Mon, 22 Aug 2022 12:06:21 +0200 From: Lars Ingebrigtsen To: Madhu Subject: Re: bug#49656: Abnormal Emacs memory usage (bug#43389) In-Reply-To: <20220822.073710.273511389537406275.enometh@meer.net> (Madhu's message of "Mon, 22 Aug 2022 07:37:10 +0530 (IST)") References: <20210721.071623.1810463348128672347.enometh@meer.net> <83y29z502z.fsf@gnu.org> <871qt9bhe1.fsf_-_@gnus.org> <20220822.073710.273511389537406275.enometh@meer.net> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAG1BMVEUpJisPDBBXVFp8 fYShoqe9vsTR09jw8fL////l0XS0AAAAAWJLR0QIht6VegAAAAd0SU1FB+YIFgoDISMY1/YAAAG4 SURBVDjLpdLNktowDABgJZPhbJU+QPDC9kohpVd2semV7sTh2tnB8gu09utX+bXD0lPFgYm+kSX/ QAa5lE+V0sYYpXayBMgQMwQUIKWslOK0Ou1kl+cARCG7kja/l3MopdwrdQ52XKlbCkVe5lyiHdHt DoAH+BGsIeJ8AtCCpzbehhYdIAMU3rf0G9oEihEEFCF4ct5tZ8B/DF0ce4AJFtTDpQPuNMKhcW3e HbGvyIYeQhtybZvXft9jc8RDB8GeZsAfZ8vDBm9mFTwcbqiximr1ikOMUDRElmy9+gCax/LuHR+B d3SZQTvV0jTE5368A77gSnN7k91BhplYE5lfeA/8Ew3ZN5GCKLkAyyWvRNejgAk+bfluS8mnZbX9 s5ZQwgBq/XTSujY88c2YqpDbAfan5VrzS2yCMzdbF7AaeuyKXDd8JFdvrCWT50NFO9Yz54fLpVU8 Esi/7VWlTr18nYCPf+PCFC8J4Cbmw8/pojgWMe8vacV/AT0EzzCb6kuE8BhccDP4HoHSneMhgVUK OoLNEhBqAn/DBJZ1hPcUPpt/wCICbxwiPFs3wUv3ZAc422sEwU8rw79xYN9+0S2V8QAAACV0RVh0 ZGF0ZTpjcmVhdGUAMjAyMi0wOC0yMlQxMDowMzozMyswMDowMLGuQFgAAAAldEVYdGRhdGU6bW9k aWZ5ADIwMjItMDgtMjJUMTA6MDM6MzMrMDA6MDDA8/jkAAAAAElFTkSuQmCC X-Now-Playing: Bertine Zetlitz's _Beautiful So Far_: "Closer" Date: Mon, 22 Aug 2022 12:06:18 +0200 Message-ID: <87sflobnj9.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Madhu writes: > No, I haven't triggered this problem recently with emacs-29. Maybe > I've stopped using the packages that triggered it. The bug should be > probably closed, Thanks OK; done. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49656 Cc: eliz@gnu.org, 49656@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Madhu writes: > No, I haven't triggered this problem recently with emacs-29. Maybe > I've stopped using the packages that triggered it. The bug should be > probably closed, Thanks OK; done. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 22 06:06:40 2022 Received: (at control) by debbugs.gnu.org; 22 Aug 2022 10:06:40 +0000 Received: from localhost ([127.0.0.1]:37935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQ4KO-0006N1-C1 for submit@debbugs.gnu.org; Mon, 22 Aug 2022 06:06:40 -0400 Received: from quimby.gnus.org ([95.216.78.240]:52310) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQ4KK-0006Ma-L4 for control@debbugs.gnu.org; Mon, 22 Aug 2022 06:06:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=5eEx5PqOs53mTDxpxKj5CcIqmYJf1d5LmQlfYdeFeKw=; b=WguXppe3ElqvJiwxTXGS/DfX2i XVqng9hNwSdkopm0vKjqfJHJL+N+OeE7lHjJsQ44ZOeMu6R8wP6bj+fefkE1EcXgV7d/hocFIXYen IK0YDKzSCXAcxWDSJtKmThpXdU/8fRzQAzFLTxqR+Cg8fUJsifj1kblK8bG9wKmDEe2o=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oQ4KC-0004G5-PZ for control@debbugs.gnu.org; Mon, 22 Aug 2022 12:06:30 +0200 Date: Mon, 22 Aug 2022 12:06:28 +0200 Message-Id: <87r118bniz.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #49656 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 49656 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 49656 quit From unknown Thu Jun 19 14:02:54 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 19 Sep 2022 11:24:11 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator