* bug#17751: 24.4.50; More memory leaks under OS X Mavericks
@ 2014-06-10 20:55 Steve Purcell
2014-06-11 3:57 ` Dmitry Antipov
2014-06-11 5:04 ` Jan Djärv
0 siblings, 2 replies; 12+ messages in thread
From: Steve Purcell @ 2014-06-10 20:55 UTC (permalink / raw)
To: 17751
Even with this recent nightly Emacs build from emacsformacosx.com, I've
been suffering from the distnoted memory/CPU-ballooning issue addressed in
#15946, with that process reaching > 100% CPU and several GB in
memory. Quitting Emacs solves the problem.
In the discussion on #15946, Jan D suggested running "leaks" on Emacs to
see what's going on, so I tried that:
Starting with an "emacs -Q", I can fire up the "leaks" command in a loop
and watch Emacs start to leak memory.
While Emacs is the front-most application and the mouse is moving above
it, new leaks appear. When the mouse stops, the leaks stop appearing.
While the cursor blinks (as it does, by default), new leaks appear. When
the cursor stops blinking after a few seconds, the leaks stop
appearing. (Unless the mouse is also moving.)
As I write this message in the clean "emacs -Q" instance, "leaks" tells
me:
Process 60460: 53511 leaks for 11106784 total leaked bytes.
So 11MB leaked in the space of a few minutes and a few lines typed, with
just a couple of buffers open!
The leaks look like this:
Leak: 0x10c1d62a0 size=160 zone: DefaultMallocZone_0x1006c5000 OS_dispatch_source ObjC libdispatch.dylib
0x762d8c20 0x00007fff 0x00000001 0x00000000 .-v............
0x89abcdef 0xffffffff 0x762da480 0x00007fff ..........-v....
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000001 0x00000000 0x00009cc4 0x00000000 ................
0x8979a90c 0x00007fff 0x014002f0 0x00000001 ..y.......@.....
0x0c1d6390 0x00000001 0x00000002 0x0000004c .c..........L...
...
Commenters in #15946 noted that they felt like application switching was
causing leaks, and what I'm seeing points to event handling or timer loops.
Any insights into what might be going on? This strikes me as a serious issue.
In GNU Emacs 24.4.50.1 (x86_64-apple-darwin, NS appkit-1038.36 Version 10.6.8 (Build 10K549))
of 2014-06-04 on bob.porkrind.org
Repository revision: eliz@gnu.org-20140604075416-fzf3twev7l2gdfgm
Windowing system distributor `Apple', version 10.3.1265
Configured using:
`configure --host=x86_64-apple-darwin --build=i686-apple-darwin
--with-ns'
Configured features:
ACL LIBXML2 ZLIB
Important settings:
value of $LC_CTYPE: en_US.UTF-8
value of $LANG: en_US
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
s-x M-x r e p o <tab> <down> r t - e m a c s <tab>
<return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
kill-region: The mark is not set now, so there is no region
Making completion list...
user-error: End of history; no default available
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel ns-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
cocoa ns multi-tty emacs)
Memory information:
((conses 16 80671 6737)
(symbols 48 18479 0)
(miscs 40 37 114)
(strings 32 12454 4751)
(string-bytes 1 326584)
(vectors 16 9358)
(vector-slots 8 370915 6294)
(floats 8 58 214)
(intervals 56 191 0)
(buffers 960 12))
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17751: 24.4.50; More memory leaks under OS X Mavericks
2014-06-10 20:55 bug#17751: 24.4.50; More memory leaks under OS X Mavericks Steve Purcell
@ 2014-06-11 3:57 ` Dmitry Antipov
2014-06-11 5:04 ` Jan Djärv
1 sibling, 0 replies; 12+ messages in thread
From: Dmitry Antipov @ 2014-06-11 3:57 UTC (permalink / raw)
To: Steve Purcell; +Cc: 17751
On 06/11/2014 12:55 AM, Steve Purcell wrote:
> The leaks look like this:
>
> Leak: 0x10c1d62a0 size=160 zone: DefaultMallocZone_0x1006c5000 OS_dispatch_source ObjC libdispatch.dylib
> 0x762d8c20 0x00007fff 0x00000001 0x00000000 .-v............
> 0x89abcdef 0xffffffff 0x762da480 0x00007fff ..........-v....
> 0x00000000 0x00000000 0x00000000 0x00000000 ................
> 0x00000000 0x00000000 0x00000000 0x00000000 ................
> 0x00000000 0x00000000 0x00000000 0x00000000 ................
> 0x00000001 0x00000000 0x00009cc4 0x00000000 ................
> 0x8979a90c 0x00007fff 0x014002f0 0x00000001 ..y.......@.....
> 0x0c1d6390 0x00000001 0x00000002 0x0000004c .c..........L...
> ...
I don't know how 'leaks' works, but this doesn't look too representative for me.
Could you please try valgrind? According to http://valgrind.org/info/platforms.html,
it should work on OSX. Unfortunately you have to compile Emacs yourself to get
bare (temacs) executable because regular binary will not work.
Dmitry
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17751: 24.4.50; More memory leaks under OS X Mavericks
2014-06-10 20:55 bug#17751: 24.4.50; More memory leaks under OS X Mavericks Steve Purcell
2014-06-11 3:57 ` Dmitry Antipov
@ 2014-06-11 5:04 ` Jan Djärv
2014-06-11 6:10 ` Jan D.
1 sibling, 1 reply; 12+ messages in thread
From: Jan Djärv @ 2014-06-11 5:04 UTC (permalink / raw)
To: Steve Purcell; +Cc: 17751
Hello.
10 jun 2014 kl. 22:55 skrev Steve Purcell <steve@sanityinc.com>:
> Even with this recent nightly Emacs build from emacsformacosx.com, I've
> been suffering from the distnoted memory/CPU-ballooning issue addressed in
> #15946, with that process reaching > 100% CPU and several GB in
> memory. Quitting Emacs solves the problem.
>
> In the discussion on #15946, Jan D suggested running "leaks" on Emacs to
> see what's going on, so I tried that:
>
> Starting with an "emacs -Q", I can fire up the "leaks" command in a loop
> and watch Emacs start to leak memory.
>
> While Emacs is the front-most application and the mouse is moving above
> it, new leaks appear. When the mouse stops, the leaks stop appearing.
>
> While the cursor blinks (as it does, by default), new leaks appear. When
> the cursor stops blinking after a few seconds, the leaks stop
> appearing. (Unless the mouse is also moving.)
>
> As I write this message in the clean "emacs -Q" instance, "leaks" tells
> me:
>
> Process 60460: 53511 leaks for 11106784 total leaked bytes.
>
> So 11MB leaked in the space of a few minutes and a few lines typed, with
> just a couple of buffers open!
>
> The leaks look like this:
>
> Leak: 0x10c1d62a0 size=160 zone: DefaultMallocZone_0x1006c5000 OS_dispatch_source ObjC libdispatch.dylib
> 0x762d8c20 0x00007fff 0x00000001 0x00000000 .-v............
> 0x89abcdef 0xffffffff 0x762da480 0x00007fff ..........-v....
> 0x00000000 0x00000000 0x00000000 0x00000000 ................
> 0x00000000 0x00000000 0x00000000 0x00000000 ................
> 0x00000000 0x00000000 0x00000000 0x00000000 ................
> 0x00000001 0x00000000 0x00009cc4 0x00000000 ................
> 0x8979a90c 0x00007fff 0x014002f0 0x00000001 ..y.......@.....
> 0x0c1d6390 0x00000001 0x00000002 0x0000004c .c..........L...
> ...
You can not tuncate leaks output without loosing important information. Post the whole leaks output, comressed.
Leaks is sometimes confused by Emacs memory allocation. Relevant output can only be gotten just after you have run garbage-collect in Emacs.
Dmitry wrote:
> I don't know how 'leaks' works, but this doesn't look too representative for me.
> Could you please try valgrind? According to http://valgrind.org/info/platforms.html,
> it should work on OSX. Unfortunately you have to compile Emacs yourself to get
> bare (temacs) executable because regular binary will not work.
Valgrind really does not work on OSX, except for the simplest programs. It is a waste of time to try it.
Jan D.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17751: 24.4.50; More memory leaks under OS X Mavericks
2014-06-11 5:04 ` Jan Djärv
@ 2014-06-11 6:10 ` Jan D.
2014-06-11 6:18 ` Jan D.
0 siblings, 1 reply; 12+ messages in thread
From: Jan D. @ 2014-06-11 6:10 UTC (permalink / raw)
To: Steve Purcell; +Cc: 17751
Jan Djärv skrev 2014-06-11 07:04:
> You can not tuncate leaks output without loosing important information. Post the whole leaks output, comressed.
>
It occurred to me that you probably did not set MallocStackLogging.
To get relevant output, more than the one you posted, you need to set
MallocStackLogging in the environment before starting Emacs, i.e.
% MallocStackLogging=1 /path/to/Emacs.app/Contents/MacOS/Emacs
Emacs will be a bit slower, but leaks output is much more useful and a
lot bigger.
Jan D.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17751: 24.4.50; More memory leaks under OS X Mavericks
2014-06-11 6:10 ` Jan D.
@ 2014-06-11 6:18 ` Jan D.
2014-06-11 7:12 ` Steve Purcell
2014-06-11 7:15 ` martin rudalics
0 siblings, 2 replies; 12+ messages in thread
From: Jan D. @ 2014-06-11 6:18 UTC (permalink / raw)
To: Steve Purcell; +Cc: 17751
Hello.
Jan D. skrev 2014-06-11 08:10:
> Jan Djärv skrev 2014-06-11 07:04:
>
>> You can not tuncate leaks output without loosing important
>> information. Post the whole leaks output, comressed.
>>
>
> It occurred to me that you probably did not set MallocStackLogging.
> To get relevant output, more than the one you posted, you need to set
> MallocStackLogging in the environment before starting Emacs, i.e.
>
> % MallocStackLogging=1 /path/to/Emacs.app/Contents/MacOS/Emacs
>
> Emacs will be a bit slower, but leaks output is much more useful and a
> lot bigger.
>
And turn off blick cursor. Otherwise Emacs will allocate some after
garbage-collect is run and leaks will report false leaks.
Jan D.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17751: 24.4.50; More memory leaks under OS X Mavericks
2014-06-11 6:18 ` Jan D.
@ 2014-06-11 7:12 ` Steve Purcell
2014-06-11 7:15 ` martin rudalics
1 sibling, 0 replies; 12+ messages in thread
From: Steve Purcell @ 2014-06-11 7:12 UTC (permalink / raw)
To: Jan D.; +Cc: 17751
Thanks Jan - I’ll give that a try and report back.
On 11 Jun 2014, at 07:18, Jan D. <jan.h.d@swipnet.se> wrote:
> Hello.
> Jan D. skrev 2014-06-11 08:10:
>> Jan Djärv skrev 2014-06-11 07:04:
>>
>>> You can not tuncate leaks output without loosing important
>>> information. Post the whole leaks output, comressed.
>>>
>>
>> It occurred to me that you probably did not set MallocStackLogging.
>> To get relevant output, more than the one you posted, you need to set
>> MallocStackLogging in the environment before starting Emacs, i.e.
>>
>> % MallocStackLogging=1 /path/to/Emacs.app/Contents/MacOS/Emacs
>>
>> Emacs will be a bit slower, but leaks output is much more useful and a
>> lot bigger.
>>
>
> And turn off blick cursor. Otherwise Emacs will allocate some after garbage-collect is run and leaks will report false leaks.
>
> Jan D.
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17751: 24.4.50; More memory leaks under OS X Mavericks
2014-06-11 6:18 ` Jan D.
2014-06-11 7:12 ` Steve Purcell
@ 2014-06-11 7:15 ` martin rudalics
2014-06-11 16:40 ` Steve Purcell
2014-06-11 17:22 ` Jan D.
1 sibling, 2 replies; 12+ messages in thread
From: martin rudalics @ 2014-06-11 7:15 UTC (permalink / raw)
To: Jan D., Steve Purcell; +Cc: 17751
> And turn off blick cursor. Otherwise Emacs will allocate some after garbage-collect is run and leaks will report false leaks.
... and what if it's the blinking cursor to cause the leaks
in the first place?
martin
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17751: 24.4.50; More memory leaks under OS X Mavericks
2014-06-11 7:15 ` martin rudalics
@ 2014-06-11 16:40 ` Steve Purcell
2014-06-11 17:29 ` Jan D.
2014-06-11 17:22 ` Jan D.
1 sibling, 1 reply; 12+ messages in thread
From: Steve Purcell @ 2014-06-11 16:40 UTC (permalink / raw)
To: martin rudalics; +Cc: 17751
Okay, done. I fired up Emacs with MallocStackLogging enabled, sent it some input events via mouse & keyboard, turned off blink-cursor-mode then ran garbage-collect. Finally I captured the leaks output, which reported 2MB leaked:
https://dl.dropboxusercontent.com/u/3739665/leaks.txt.gz
On 11 Jun 2014, at 08:15, martin rudalics <rudalics@gmx.at> wrote:
> > And turn off blick cursor. Otherwise Emacs will allocate some after garbage-collect is run and leaks will report false leaks.
>
> ... and what if it's the blinking cursor to cause the leaks
> in the first place?
>
> martin
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17751: 24.4.50; More memory leaks under OS X Mavericks
2014-06-11 7:15 ` martin rudalics
2014-06-11 16:40 ` Steve Purcell
@ 2014-06-11 17:22 ` Jan D.
1 sibling, 0 replies; 12+ messages in thread
From: Jan D. @ 2014-06-11 17:22 UTC (permalink / raw)
To: martin rudalics, Steve Purcell; +Cc: 17751
martin rudalics skrev 2014-06-11 09:15:
> > And turn off blick cursor. Otherwise Emacs will allocate some after
> garbage-collect is run and leaks will report false leaks.
>
> ... and what if it's the blinking cursor to cause the leaks
> in the first place?
>
It is not, I checked.
Jan D.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17751: 24.4.50; More memory leaks under OS X Mavericks
2014-06-11 16:40 ` Steve Purcell
@ 2014-06-11 17:29 ` Jan D.
[not found] ` <099A5827-C02A-40E6-AA0B-2836CCE9A907@sanityinc.com>
0 siblings, 1 reply; 12+ messages in thread
From: Jan D. @ 2014-06-11 17:29 UTC (permalink / raw)
To: Steve Purcell; +Cc: 17751
Steve Purcell skrev 2014-06-11 18:40:
> Okay, done. I fired up Emacs with MallocStackLogging enabled, sent it some input events via mouse & keyboard, turned off blink-cursor-mode then ran garbage-collect. Finally I captured the leaks output, which reported 2MB leaked:
>
> https://dl.dropboxusercontent.com/u/3739665/leaks.txt.gz
>
Are you still using nightlies from emacsformacosx.com?
This:
Call stack: [thread 0x7fff76a9b310]: | start | main |
Frecursive_edit | recursive_edit_1 | internal_catch | command_loop_2 |
internal_condition_case | command_loop_1 | read_key_sequence | read_char
| detect_input_pending_run_timers | gobble_input | ns_read_socket |
-[NSApplication run] | -[NSApplication
_installMemoryPressureDispatchSources] | dispatch_source_create |
_os_object_alloc_realized | class_createInstance | calloc |
malloc_zone_calloc
Leak: 0x10080b650 size=16 zone: DefaultMallocZone_0x1006cb000
shows that Emacs is not built on OSX 10.9 where it is run.
This is an OSX bug with 10.9 that we have worked around, but only if
Emacs is built on 10.9. I guess that is your problem right there.
I could try to make it a runtime check instead.
Jan D.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17751: 24.4.50; More memory leaks under OS X Mavericks
[not found] ` <099A5827-C02A-40E6-AA0B-2836CCE9A907@sanityinc.com>
@ 2014-06-11 18:05 ` Jan D.
2015-12-26 15:27 ` Lars Ingebrigtsen
0 siblings, 1 reply; 12+ messages in thread
From: Jan D. @ 2014-06-11 18:05 UTC (permalink / raw)
To: Steve Purcell; +Cc: 17751
Steve Purcell skrev 2014-06-11 19:37:
> Yes! That would make sense. Let me compile locally and repeat the experiment...
>
I checked in a change in trunk where I made the check at runtime.
Also, another (but unrelated to distnoted) leak was plugged.
Jan D.
>
> On 11 Jun 2014, at 18:29, Jan D. <jan.h.d@swipnet.se> wrote:
>
>> Steve Purcell skrev 2014-06-11 18:40:
>>> Okay, done. I fired up Emacs with MallocStackLogging enabled, sent it some input events via mouse & keyboard, turned off blink-cursor-mode then ran garbage-collect. Finally I captured the leaks output, which reported 2MB leaked:
>>>
>>> https://dl.dropboxusercontent.com/u/3739665/leaks.txt.gz
>>>
>>
>> Are you still using nightlies from emacsformacosx.com?
>> This:
>>
>> Call stack: [thread 0x7fff76a9b310]: | start | main | Frecursive_edit | recursive_edit_1 | internal_catch | command_loop_2 | internal_condition_case | command_loop_1 | read_key_sequence | read_char | detect_input_pending_run_timers | gobble_input | ns_read_socket | -[NSApplication run] | -[NSApplication _installMemoryPressureDispatchSources] | dispatch_source_create | _os_object_alloc_realized | class_createInstance | calloc | malloc_zone_calloc
>> Leak: 0x10080b650 size=16 zone: DefaultMallocZone_0x1006cb000
>>
>> shows that Emacs is not built on OSX 10.9 where it is run.
>> This is an OSX bug with 10.9 that we have worked around, but only if Emacs is built on 10.9. I guess that is your problem right there.
>>
>> I could try to make it a runtime check instead.
>>
>> Jan D.
>>
>>
>>
>>
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17751: 24.4.50; More memory leaks under OS X Mavericks
2014-06-11 18:05 ` Jan D.
@ 2015-12-26 15:27 ` Lars Ingebrigtsen
0 siblings, 0 replies; 12+ messages in thread
From: Lars Ingebrigtsen @ 2015-12-26 15:27 UTC (permalink / raw)
To: Jan D.; +Cc: Steve Purcell, 17751
"Jan D." <jan.h.d@swipnet.se> writes:
> Steve Purcell skrev 2014-06-11 19:37:
>> Yes! That would make sense. Let me compile locally and repeat the experiment...
>>
>
> I checked in a change in trunk where I made the check at runtime.
> Also, another (but unrelated to distnoted) leak was plugged.
This means that this bug is fixed, I guess? I'm closing the report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2015-12-26 15:27 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-10 20:55 bug#17751: 24.4.50; More memory leaks under OS X Mavericks Steve Purcell
2014-06-11 3:57 ` Dmitry Antipov
2014-06-11 5:04 ` Jan Djärv
2014-06-11 6:10 ` Jan D.
2014-06-11 6:18 ` Jan D.
2014-06-11 7:12 ` Steve Purcell
2014-06-11 7:15 ` martin rudalics
2014-06-11 16:40 ` Steve Purcell
2014-06-11 17:29 ` Jan D.
[not found] ` <099A5827-C02A-40E6-AA0B-2836CCE9A907@sanityinc.com>
2014-06-11 18:05 ` Jan D.
2015-12-26 15:27 ` Lars Ingebrigtsen
2014-06-11 17:22 ` Jan D.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).