Emacs › Emacs - Bugs

bug#15946: 24.3; Mac OS X, Mavericks, distnoted process

Classic

List

Threaded

38 messages Options

Matthew Leach

bug#15946: 24.3; Mac OS X, Mavericks, distnoted process

Jan Djärv <[hidden email]> writes:

> They are not all like that, somewhere in there is the real leak. You
> need to save all output, and put it somewhere it can be read. If it
> is large, better not send it to the list. But if you are doing this,
> do it on a more recent version than 24.3.

Trunk Emacs seems okay, I get a much smaller output from leaks. There
are some leaks in there that I think are worth a look though, see
attached.

I just downloaded Emacs for OS X does and it defiantly has a problem with
leaking, a freshly started Emacs already generates over a MB of output
with leaks.

--
Matt

Process: Emacs [21591]
Path: /Users/matthew/Development/emacs/build/nextstep/Emacs.app/Contents/MacOS/Emacs
Load Address: 0x100000000
Identifier: org.gnu.Emacs
Version: Version 24.3.50 (9.0)
Code Type: X86-64
Parent Process: launchd [158]

Date/Time: 2014-01-14 22:46:37.788 +0000
OS Version: Mac OS X 10.9.1 (13B42)
Report Version: 7

leaks Report Version: 2.0
Process 21591: 69442 nodes malloced for 37557 KB
Process 21591: 13 leaks for 17264 total leaked bytes.
Leak: 0x13124d800 size=16384 zone: MallocHelperZone_0x10081a000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x000b0007 0x00000003 0x00030008 0x00000000 ................
0x00000000 0x00000000 0x00000020 0x0000003a ........ ...:...
0x00000125 0x00000000 0x0d565875 0x00000001 %.......uXV.....
0x0010000a 0x00000004 0x00008008 0x0000002f ............/...
0x00000000 0x00000000 0x0000004e 0x53256e3c ........N...<n%S
0x00000126 0x00000000 0x0d565875 0x00000001 &.......uXV.....
0x0010000a 0x00000004 0x13c48008 0x4900002f ............/..I
...
Leak: 0x6000000b48e0 size=96 zone: DefaultMallocZone_0x10084a000 NSMenuItem ObjC AppKit
0x7f6407a8 0x00007fff 0x00283250 0x00006000 ..d.....P2(..`..
0x00652a20 0x00006000 0x005170b0 0x00000001 *e..`...pQ.....
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x001eda7a 0x00000001 ........z.......
0x0996fd90 0x00000001 0x00000010 0x00000001 ................
Leak: 0x6000000b4c40 size=96 zone: DefaultMallocZone_0x10084a000 NSMenuItem ObjC AppKit
0x7f6407a8 0x00007fff 0x00283250 0x00006000 ..d.....P2(..`..
0x00656c20 0x00006000 0x005170b0 0x00000001 le..`...pQ.....
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x001eda7a 0x00000001 ........z.......
0x00000000 0x00000000 0x00000010 0x00000101 ................
Leak: 0x6000000b58a0 size=96 zone: DefaultMallocZone_0x10084a000 NSMenuItem ObjC AppKit
0x7f6407a8 0x00007fff 0x00283250 0x00006000 ..d.....P2(..`..
0x7f6565c8 0x00007fff 0x7f6565c8 0x00007fff .ee......ee.....
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000010 0x00000301 ................
Leak: 0x6000000b65c0 size=96 zone: DefaultMallocZone_0x10084a000 NSMenuItem ObjC AppKit
0x7f6407a8 0x00007fff 0x00283250 0x00006000 ..d.....P2(..`..
0x0064f5d0 0x00006000 0x005170b0 0x00000001 ..d..`...pQ.....
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x001eda7a 0x00000001 ........z.......
0x0996fd50 0x00000001 0x00000010 0x00000001 P...............
Leak: 0x6000000d4ac0 size=112 zone: DefaultMallocZone_0x10084a000 NSCarbonMenuImpl ObjC AppKit
0x7f63c068 0x00007fff 0x00283250 0x00006000 h.c.....P2(..`..
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x80000000 0xffffffff ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x60000023b820 size=32 zone: DefaultMallocZone_0x10084a000
0x000b4c40 0x00006000 0x000b58a0 0x00006000 @L...`...X...`..
0x000b65c0 0x00006000 0x000b48e0 0x00006000 .e...`...H...`..
Leak: 0x600000283250 size=80 zone: DefaultMallocZone_0x10084a000 EmacsMenu ObjC Emacs
0x001fead0 0x00000001 0x00000000 0x00000000 ................
0x00656c80 0x00006000 0x00653410 0x00006000 .le..`...4e..`..
0x00284650 0x00006000 0x00000001 0x00000000 PF(..`..........
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00100000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x600000284650 size=80 zone: DefaultMallocZone_0x10084a000 _NSMenuImpl ObjC AppKit
0x7f6406b8 0x00007fff 0x000d4ac0 0x00006000 ..d......J...`..
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x60000064f5d0 size=48 zone: DefaultMallocZone_0x10084a000 __NSCFString ObjC CoreFoundation "Turn Off minor mode"
Leak: 0x600000653410 size=48 zone: DefaultMallocZone_0x10084a000 __NSArrayM ObjC CoreFoundation item count: 4
Leak: 0x600000656c20 size=48 zone: DefaultMallocZone_0x10084a000 __NSCFString ObjC CoreFoundation " from font-lock.el"
Leak: 0x600000656c80 size=48 zone: DefaultMallocZone_0x10084a000 __NSCFString ObjC CoreFoundation " from font-lock.el"

Jan D.-2

bug#15946: 24.3; Mac OS X, Mavericks, distnoted process

In reply to this post by Jan D.-2

Hi.

14 jan 2014 kl. 23:17 skrev Jonathan Payne <[hidden email]>:

> Hi Jan,
>
> [Removed the list from this email]

Don't do that unless you are attaching something big.

>
> Are there already-compiled versions out there? Or do I have to download the toolchain to build it myself? I am not sure I want to go there... even though I think I already have the necessary toolchain installed ...

http://emacsforosx.com/builds has nightlies. Use the newest of those.

Jan D.

>
> Regarding the leaks in my previous message, each line output says "Leak: ...". So I think by definition it's a leak: there are no pointers or "maybe pointers" pointing to the block in question. If the blocks are all pointing to each other, then the leak could be that the first block is not being pointed to, but regardless they are all unreachable by anything looking like a pointer in all of the stacks and heap and static memory of the process.
>

I forgot, you should start your Emacs like this:

% MallocStackLogging=1 .../pah/to/Emacs.app/Contents/MacOS/Emacs

and then run leaks. It will then print a stack trace also. This may slow Emacs down a bit.

Jan D.

Jan D.-2

bug#15946: 24.3; Mac OS X, Mavericks, distnoted process

In reply to this post by Matthew Leach

Hello.

Matthew Leach skrev 2014-01-14 23:59:

>
> Jan Djärv <[hidden email]> writes:
>
>> They are not all like that, somewhere in there is the real leak. You
>> need to save all output, and put it somewhere it can be read. If it
>> is large, better not send it to the list. But if you are doing this,
>> do it on a more recent version than 24.3.
>
> Trunk Emacs seems okay, I get a much smaller output from leaks. There
> are some leaks in there that I think are worth a look though, see
> attached.
>
> I just downloaded Emacs for OS X does and it defiantly has a problem with
> leaking, a freshly started Emacs already generates over a MB of output
> with leaks.
>

Can you run this again, but with MallocStackLogging set? I.e.:

% MallocStackLogging=1 .../path/to/Emacs.app/Contents/MacOS/Emacs

And if you can, briefly describe what you did in Emacs before running
leaks.

Thanks,

Jan D.

Matthew Leach

bug#15946: 24.3; Mac OS X, Mavericks, distnoted process

"Jan D." <[hidden email]> writes:

> Can you run this again, but with MallocStackLogging set? I.e.:
>
> % MallocStackLogging=1 .../path/to/Emacs.app/Contents/MacOS/Emacs
>
> And if you can, briefly describe what you did in Emacs before running
> leaks.

Sure, see [1].

I simply did C-h v font-lock <TAB> to bring up a completion buffer, then
added -keywords <RET> to bring up the help buffer and followed the
reference to font-lock.el. That seemed to cause the leaks.

[1]: https://gist.github.com/anonymous/8434281

--
Matt

canoeberry

bug#15946: 24.3; Mac OS X, Mavericks, distnoted process

In reply to this post by Jan D.-2

I have downloaded the nightly and my problem is solved. Neither distnoted nor emacs is leaking anymore.

Well - ok there is apparently one leak occurring in emacs. It looks sort of like a string with a regular expression in it:

leaks Report Version: 2.0
Process 634: 59789 nodes malloced for 19799 KB
Process 634: 1 leak for 16384 total leaked bytes.
Leak: 0x100e20600 size=16384 zone: DefaultMallocZone_0x100687000
0x00000000 0x50000000 0x00000000 0x50000000 .......P.......P
0x00000000 0x00000000 0x0000004b 0x00000000 ........K.......
0x74696e69 0x4e7c5c79 0x7c5c4e61 0x75677261 inity\|NaN\|argu
0x746e656d 0x667c5c73 0x65736c61 0x756e7c5c ments\|false\|nu
0x7c5c6c6c 0x3f285c74 0x7369683a 0x75727c5c ll\|t\(?:his\|ru
0x5c295c65 0x646e757c 0x6e696665 0x295c6465 e\)\|undefined\)
0x003e5f5c 0x00000000 0x00000000 0x00000000 \_>.............
0x00000012 0x00000000 0x7079746f 0x5c295c65 ........otype\)\
...

So, I think this was caused by turning on flyspell-mode. The size is 16k which just reeks of two 8k buffers associated with a pipe or something.

Thanks for all the help with this issue.

On 15 Jan 2014, at 06:26, Jan Djärv <[hidden email]> wrote:

Hi.

14 jan 2014 kl. 23:17 skrev Jonathan Payne <[hidden email]>:

Hi Jan,

[Removed the list from this email]

Don't do that unless you are attaching something big.

Are there already-compiled versions out there? Or do I have to download the toolchain to build it myself? I am not sure I want to go there... even though I think I already have the necessary toolchain installed ...

http://emacsforosx.com/builds has nightlies. Use the newest of those.

Jan D.

Regarding the leaks in my previous message, each line output says "Leak: ...". So I think by definition it's a leak: there are no pointers or "maybe pointers" pointing to the block in question. If the blocks are all pointing to each other, then the leak could be that the first block is not being pointed to, but regardless they are all unreachable by anything looking like a pointer in all of the stacks and heap and static memory of the process.

I forgot, you should start your Emacs like this:

% MallocStackLogging=1 .../pah/to/Emacs.app/Contents/MacOS/Emacs

and then run leaks. It will then print a stack trace also. This may slow Emacs down a bit.

Jan D.

Jonathan Payne

vbeffara

Re: bug#15946: 24.3; Mac OS X, Mavericks, distnoted process

Hi,

Just one thing I noticed, whenever the system is in "leak mode" between distnoted and emacs: one way to trigger a CPU use spike is to change ambient light level (say by covering the sensor with your hand). Might be useful in reproducing / tracing whatever is happening in distnoted ...

(using GNU Emacs 24.3.50.1 from homebrew)

/v

canoeberry

Re: bug#15946: 24.3; Mac OS X, Mavericks, distnoted process

I had downloaded a nightly and was so happy to see that the memory leak was gone. However, the nightly has a ton of other problems with a package that is near and dear to my heart at the moment: mumamo.

So I have downloaded the source and compiled it and tried to patch it with the suggestion involving a patch early in this bug report, but that has not solved the problem. Then I remembered that I could get stack traces, which I have done:

Call stack: [thread 0x7fff71dce310]: | 0x1 | start | main emacs.c:1528 | Frecursive_edit keyboard.c:844 | recursive_edit_1 keyboard.c:1148 | internal_catch eval.c:1060 | command_loop_2 keyboard.c:1168 | internal_condition_case eval.c:1290 | command_loop_1 keyboard.c:1459 | read_key_sequence keyboard.c:9234 | read_char keyboard.c:2059 | wait_reading_process_output process.c:4743 | detect_input_pending_run_timers keyboard.c:6680 | readable_events keyboard.c:3355 | timer_check keyboard.c:4378 | call1 eval.c:2572 | Ffuncall eval.c:2850 | funcall_lambda eval.c:3010 | exec_byte_code bytecode.c:1096 | internal_lisp_condition_case eval.c:1243 | eval_sub eval.c:2149 | exec_byte_code bytecode.c:900 | Ffuncall eval.c:2759 | Fapply eval.c:2255 | Ffuncall eval.c:2850 | funcall_lambda eval.c:3010 | exec_byte_code bytecode.c:900 | Ffuncall eval.c:2775 | Finput_pending_p keyboard.c:6687 | gobble_input keyboard.c:6768 | ns_read_socket nsterm.m:3424 | -[NSApplication run] | -[NSApplication _installMemoryStatusDispatchSources] | dispatch_source_create | _os_object_alloc_realized | class_createInstance | calloc | malloc_zone_calloc
Leak: 0x1040efe20 size=160 zone: DefaultMallocZone_0x100630000 OS_dispatch_source ObjC libdispatch.dylib
0x71162c20 0x00007fff 0x00000001 0x00000000 ,.q............
0x89abcdef 0xffffffff 0x71164480 0x00007fff .........D.q....
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000001 0x00000000 0x00000175 0x00000000 ........u.......
0x8316090c 0x00007fff 0x00804760 0x00000001 ........`G......
0x040e2120 0x00000001 0x00000002 0x0000004c !..........L...
...

The last line of code in emacs that produces this leak is:

if (++apploopnr != 1)
{
emacs_abort ();
}
[NSApp run];
--apploopnr;

well it's the --apploopnr according to leaks! A little weird if you ask me.

Anyway - does anybody have any insights into this?

Jonathan Payne

Jan D.-2

bug#15946: 24.3; Mac OS X, Mavericks, distnoted process

Hello.

18 jan 2014 kl. 23:52 skrev canoeberry <[hidden email]>:

> I had downloaded a nightly and was so happy to see that the memory leak was
> gone. However, the nightly has a ton of other problems with a package that
> is near and dear to my heart at the moment: mumamo.
>
> So I have downloaded the source and compiled it and tried to patch it with
> the suggestion involving a patch early in this bug report, but that has not
> solved the problem. Then I remembered that I could get stack traces, which I
> have done:

You are better off trying to get mumamo working with trunk. There are so many differences between 24.3 and trunk. It is no trivial task to identify which has memory leak fixes.

>
> Call stack: [thread 0x7fff71dce310]: | 0x1 | start | main emacs.c:1528 |
> Frecursive_edit keyboard.c:844 | recursive_edit_1 keyboard.c:1148 |
> internal_catch eval.c:1060 | command_loop_2 keyboard.c:1168 |
> internal_condition_case eval.c:1290 | command_loop_1 keyboard.c:1459 |
> read_key_sequence keyboard.c:9234 | read_char keyboard.c:2059 |
> wait_reading_process_output process.c:4743 | detect_input_pending_run_timers
> keyboard.c:6680 | readable_events keyboard.c:3355 | timer_check
> keyboard.c:4378 | call1 eval.c:2572 | Ffuncall eval.c:2850 | funcall_lambda
> eval.c:3010 | exec_byte_code bytecode.c:1096 | internal_lisp_condition_case
> eval.c:1243 | eval_sub eval.c:2149 | exec_byte_code bytecode.c:900 |
> Ffuncall eval.c:2759 | Fapply eval.c:2255 | Ffuncall eval.c:2850 |
> funcall_lambda eval.c:3010 | exec_byte_code bytecode.c:900 | Ffuncall
> eval.c:2775 | Finput_pending_p keyboard.c:6687 | gobble_input
> keyboard.c:6768 | ns_read_socket nsterm.m:3424 | -[NSApplication run] |
> -[NSApplication _installMemoryStatusDispatchSources] |
> dispatch_source_create | _os_object_alloc_realized | class_createInstance |
> calloc | malloc_zone_calloc
> Leak: 0x1040efe20 size=160 zone: DefaultMallocZone_0x100630000
> OS_dispatch_source ObjC libdispatch.dylib
> 0x71162c20 0x00007fff 0x00000001 0x00000000 ,.q............
> 0x89abcdef 0xffffffff 0x71164480 0x00007fff .........D.q....
> 0x00000000 0x00000000 0x00000000 0x00000000 ................
> 0x00000000 0x00000000 0x00000000 0x00000000 ................
> 0x00000000 0x00000000 0x00000000 0x00000000 ................
> 0x00000001 0x00000000 0x00000175 0x00000000 ........u.......
> 0x8316090c 0x00007fff 0x00804760 0x00000001 ........`G......
> 0x040e2120 0x00000001 0x00000002 0x0000004c !..........L...
> ...
>
> The last line of code in emacs that produces this leak is:
>
> if (++apploopnr != 1)
> {
> emacs_abort ();
> }
> [NSApp run];
> --apploopnr;
>
> well it's the --apploopnr according to leaks! A little weird if you ask me.

The stack trace clearly states that it is in NSApp run (i.e. NSApplication run), so the trace is off by one line. This happens often.

Jan D.

canoeberry

Re: bug#15946: 24.3; Mac OS X, Mavericks, distnoted process

Ironically, the leak was fixed by ... YOU!

On 19 Jan 2014, at 09:34, Jan Djärv [via Emacs] <[hidden email]> wrote:

Hello.

18 jan 2014 kl. 23:52 skrev canoeberry <<a href="x-msg://11/user/SendEmail.jtp?type=node&node=310868&i=0" target="_top" rel="nofollow" link="external">[hidden email]>:

> I had downloaded a nightly and was so happy to see that the memory leak was
> gone. However, the nightly has a ton of other problems with a package that
> is near and dear to my heart at the moment: mumamo.
>
> So I have downloaded the source and compiled it and tried to patch it with
> the suggestion involving a patch early in this bug report, but that has not
> solved the problem. Then I remembered that I could get stack traces, which I
> have done:

You are better off trying to get mumamo working with trunk. There are so many differences between 24.3 and trunk. It is no trivial task to identify which has memory leak fixes.

>
> Call stack: [thread 0x7fff71dce310]: | 0x1 | start | main emacs.c:1528 |
> Frecursive_edit keyboard.c:844 | recursive_edit_1 keyboard.c:1148 |
> internal_catch eval.c:1060 | command_loop_2 keyboard.c:1168 |
> internal_condition_case eval.c:1290 | command_loop_1 keyboard.c:1459 |
> read_key_sequence keyboard.c:9234 | read_char keyboard.c:2059 |
> wait_reading_process_output process.c:4743 | detect_input_pending_run_timers
> keyboard.c:6680 | readable_events keyboard.c:3355 | timer_check
> keyboard.c:4378 | call1 eval.c:2572 | Ffuncall eval.c:2850 | funcall_lambda
> eval.c:3010 | exec_byte_code bytecode.c:1096 | internal_lisp_condition_case
> eval.c:1243 | eval_sub eval.c:2149 | exec_byte_code bytecode.c:900 |
> Ffuncall eval.c:2759 | Fapply eval.c:2255 | Ffuncall eval.c:2850 |
> funcall_lambda eval.c:3010 | exec_byte_code bytecode.c:900 | Ffuncall
> eval.c:2775 | Finput_pending_p keyboard.c:6687 | gobble_input
> keyboard.c:6768 | ns_read_socket nsterm.m:3424 | -[NSApplication run] |
> -[NSApplication _installMemoryStatusDispatchSources] |
> dispatch_source_create | _os_object_alloc_realized | class_createInstance |
> calloc | malloc_zone_calloc
> Leak: 0x1040efe20 size=160 zone: DefaultMallocZone_0x100630000
> OS_dispatch_source ObjC libdispatch.dylib
> 0x71162c20 0x00007fff 0x00000001 0x00000000 ,.q............
> 0x89abcdef 0xffffffff 0x71164480 0x00007fff .........D.q....
> 0x00000000 0x00000000 0x00000000 0x00000000 ................
> 0x00000000 0x00000000 0x00000000 0x00000000 ................
> 0x00000000 0x00000000 0x00000000 0x00000000 ................
> 0x00000001 0x00000000 0x00000175 0x00000000 ........u.......
> 0x8316090c 0x00007fff 0x00804760 0x00000001 ........`G......
> 0x040e2120 0x00000001 0x00000002 0x0000004c !..........L...
> ...
>
> The last line of code in emacs that produces this leak is:
>
> if (++apploopnr != 1)
> {
> emacs_abort ();
> }
> [NSApp run];
> --apploopnr;
>
> well it's the --apploopnr according to leaks! A little weird if you ask me.
The stack trace clearly states that it is in NSApp run (i.e. NSApplication run), so the trace is off by one line. This happens often.

Jan D.

If you reply to this email, your message will be added to the discussion below:
http://emacs.1067599.n5.nabble.com/bug-15946-24-3-Mac-OS-X-Mavericks-distnoted-process-tp303500p310868.html

To unsubscribe from bug#15946: 24.3; Mac OS X, Mavericks, distnoted process, click here.
NAML

Jonathan Payne

SB-6

bug#15946: 24.3; Mac OS X, Mavericks, distnoted process

After reading reports in this thread that it was fixed in the trunk I
went and applied the aforementioned inline patch to the current trunk
and indeed the distnoted issue seems fixed. Whereas with my patch to
the inline patch the problem seemed a little more tolerable and still
required occasionally killing distnoted (and Emacs.app crashed
although less frequently).

If there is a single commit that can make distnoted behave, it may be
in the interest of others using Mavericks to have this incorporated
into an official point release and close this bug (the distnoted bug
for those affected can be quite severe, locking up the entire machine
in my case). Mavericks is inevitable for many mac users and some
people may not be ready to transition to 24.4 for whatever reasons.

The modified inline patch (only relevant if you use Japanese or some
other language for writing text in Emacs and want seamless language
switching while using various keys/commands) for the current trunk:

https://gist.github.com/anonymous/8517045

On Sun, Jan 19, 2014 at 7:49 PM, canoeberry <[hidden email]> wrote:

> Ironically, the leak was fixed by ... YOU!
>
> On 19 Jan 2014, at 09:34, Jan Djärv [via Emacs] <[hidden email]> wrote:
>
> Hello.
>
> 18 jan 2014 kl. 23:52 skrev canoeberry <<a
> href="x-msg://11/user/SendEmail.jtp?type=node&node=310868&i=0"
> target="_top" rel="nofollow" link="external">[hidden email]>:
>
>> I had downloaded a nightly and was so happy to see that the memory leak
>> was
>> gone. However, the nightly has a ton of other problems with a package that
>> is near and dear to my heart at the moment: mumamo.
>>
>> So I have downloaded the source and compiled it and tried to patch it with
>> the suggestion involving a patch early in this bug report, but that has
>> not
>> solved the problem. Then I remembered that I could get stack traces, which
>> I
>> have done:
>
> You are better off trying to get mumamo working with trunk. There are so
> many differences between 24.3 and trunk. It is no trivial task to identify
> which has memory leak fixes.
>
>>
>> Call stack: [thread 0x7fff71dce310]: | 0x1 | start | main emacs.c:1528 |
>> Frecursive_edit keyboard.c:844 | recursive_edit_1 keyboard.c:1148 |
>> internal_catch eval.c:1060 | command_loop_2 keyboard.c:1168 |
>> internal_condition_case eval.c:1290 | command_loop_1 keyboard.c:1459 |
>> read_key_sequence keyboard.c:9234 | read_char keyboard.c:2059 |
>> wait_reading_process_output process.c:4743 |
>> detect_input_pending_run_timers
>> keyboard.c:6680 | readable_events keyboard.c:3355 | timer_check
>> keyboard.c:4378 | call1 eval.c:2572 | Ffuncall eval.c:2850 |
>> funcall_lambda
>> eval.c:3010 | exec_byte_code bytecode.c:1096 |
>> internal_lisp_condition_case
>> eval.c:1243 | eval_sub eval.c:2149 | exec_byte_code bytecode.c:900 |
>> Ffuncall eval.c:2759 | Fapply eval.c:2255 | Ffuncall eval.c:2850 |
>> funcall_lambda eval.c:3010 | exec_byte_code bytecode.c:900 | Ffuncall
>> eval.c:2775 | Finput_pending_p keyboard.c:6687 | gobble_input
>> keyboard.c:6768 | ns_read_socket nsterm.m:3424 | -[NSApplication run] |
>> -[NSApplication _installMemoryStatusDispatchSources] |
>> dispatch_source_create | _os_object_alloc_realized | class_createInstance
>> |
>> calloc | malloc_zone_calloc
>> Leak: 0x1040efe20 size=160 zone: DefaultMallocZone_0x100630000
>> OS_dispatch_source ObjC libdispatch.dylib
>> 0x71162c20 0x00007fff 0x00000001 0x00000000 ,.q............
>> 0x89abcdef 0xffffffff 0x71164480 0x00007fff .........D.q....
>> 0x00000000 0x00000000 0x00000000 0x00000000 ................
>> 0x00000000 0x00000000 0x00000000 0x00000000 ................
>> 0x00000000 0x00000000 0x00000000 0x00000000 ................
>> 0x00000001 0x00000000 0x00000175 0x00000000 ........u.......
>> 0x8316090c 0x00007fff 0x00804760 0x00000001 ........`G......
>> 0x040e2120 0x00000001 0x00000002 0x0000004c !..........L...
>> ...
>>
>> The last line of code in emacs that produces this leak is:
>>
>> if (++apploopnr != 1)
>> {
>> emacs_abort ();
>> }
>> [NSApp run];
>> --apploopnr;
>>
>> well it's the --apploopnr according to leaks! A little weird if you ask
>> me.
> The stack trace clearly states that it is in NSApp run (i.e. NSApplication
> run), so the trace is off by one line. This happens often.
>
> Jan D.
>
>
>
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://emacs.1067599.n5.nabble.com/bug-15946-24-3-Mac-OS-X-Mavericks-distnoted-process-tp303500p310868.html
> To unsubscribe from bug#15946: 24.3; Mac OS X, Mavericks, distnoted process,
> click here.
> NAML
>
>
> Jonathan Payne
>
> ________________________________
> View this message in context: Re: bug#15946: 24.3; Mac OS X, Mavericks,
> distnoted process
> Sent from the Emacs - Bugs mailing list archive at Nabble.com.

Jonathan Payne-2

bug#15946: a patch against emacs 24.3.1 for fixing the distnoted memory leak

In reply to this post by Donald Tillman

This is FYI for people who do not want to wait for emacs 24.4 and cannot use one of the current nightlies to get around the Mavericks distnoted issue.

I am not a Mac programmer unfortunately, so take this with a grain of salt. My analysis of the problem is this:

1) When Mavericks came out a memory leak was discovered and fixed by Jan D. who is a frequent contributor to ns (Next Step) emacs for Mac OS X.

2) His fix, I think, was to avoid calling Application.run 20 times / second by introducing a variable called "shouldKeepRunning" into the Application.run method.

3) Repeatedly calling Application.run was causing a 160 byte leak each time inside emacs. But I think it was also causing a problem with distnoted, and I am speculating (knowing NOTHING ABOUT IT) that each call to run() was causing some sort of registration with distnoted. That registration, I assume, creates some sort of context in distnoted that is substantially larger than 160 bytes. So the leak in emacs was relatively slow, the one in distnoted was much larger.

This would also explain why distnoted would get slower as time goes by because it has hundreds of thousands of registrations, all for emacs, which I assume it was still trying to deliver notifications to, but really, I have no idea what I am talking about.

So, I applied part of Jan D's patch to emacs-24.3 that addressed this particular problem, and presto-chango, the leak is gone, distnoted is happy, and all my current elisp packages work because it's still emacs-24.3 and not emacs-24.4 which I assume is what's being created in the trunk today.

So - should I post this particular patch some place? Are other people interested in having this patch?

JP

Jan D.-2

bug#15946: 24.3; Mac OS X, Mavericks, distnoted process

In reply to this post by SB-6

Hello.

20 jan 2014 kl. 10:53 skrev SB <[hidden email]>:

> After reading reports in this thread that it was fixed in the trunk I
> went and applied the aforementioned inline patch to the current trunk
> and indeed the distnoted issue seems fixed. Whereas with my patch to
> the inline patch the problem seemed a little more tolerable and still
> required occasionally killing distnoted (and Emacs.app crashed
> although less frequently).
>
> If there is a single commit that can make distnoted behave, it may be
> in the interest of others using Mavericks to have this incorporated
> into an official point release and close this bug (the distnoted bug
> for those affected can be quite severe, locking up the entire machine
> in my case). Mavericks is inevitable for many mac users and some
> people may not be ready to transition to 24.4 for whatever reasons.

There will not be any release for the 24.3 branch. 24.4 is next.

>
> The modified inline patch (only relevant if you use Japanese or some
> other language for writing text in Emacs and want seamless language
> switching while using various keys/commands) for the current trunk:
>
> https://gist.github.com/anonymous/8517045

The patch is way too big to be incorporated into Emacs in the current feature freeze.

Jan D.

>
> On Sun, Jan 19, 2014 at 7:49 PM, canoeberry <[hidden email]> wrote:
>> Ironically, the leak was fixed by ... YOU!
>>
>> On 19 Jan 2014, at 09:34, Jan Djärv [via Emacs] <[hidden email]> wrote:
>>
>> Hello.
>>
>> 18 jan 2014 kl. 23:52 skrev canoeberry <<a
>> href="x-msg://11/user/SendEmail.jtp?type=node&node=310868&i=0"
>> target="_top" rel="nofollow" link="external">[hidden email]>:
>>
>>> I had downloaded a nightly and was so happy to see that the memory leak
>>> was
>>> gone. However, the nightly has a ton of other problems with a package that
>>> is near and dear to my heart at the moment: mumamo.
>>>
>>> So I have downloaded the source and compiled it and tried to patch it with
>>> the suggestion involving a patch early in this bug report, but that has
>>> not
>>> solved the problem. Then I remembered that I could get stack traces, which
>>> I
>>> have done:
>>
>> You are better off trying to get mumamo working with trunk. There are so
>> many differences between 24.3 and trunk. It is no trivial task to identify
>> which has memory leak fixes.
>>
>>>
>>> Call stack: [thread 0x7fff71dce310]: | 0x1 | start | main emacs.c:1528 |
>>> Frecursive_edit keyboard.c:844 | recursive_edit_1 keyboard.c:1148 |
>>> internal_catch eval.c:1060 | command_loop_2 keyboard.c:1168 |
>>> internal_condition_case eval.c:1290 | command_loop_1 keyboard.c:1459 |
>>> read_key_sequence keyboard.c:9234 | read_char keyboard.c:2059 |
>>> wait_reading_process_output process.c:4743 |
>>> detect_input_pending_run_timers
>>> keyboard.c:6680 | readable_events keyboard.c:3355 | timer_check
>>> keyboard.c:4378 | call1 eval.c:2572 | Ffuncall eval.c:2850 |
>>> funcall_lambda
>>> eval.c:3010 | exec_byte_code bytecode.c:1096 |
>>> internal_lisp_condition_case
>>> eval.c:1243 | eval_sub eval.c:2149 | exec_byte_code bytecode.c:900 |
>>> Ffuncall eval.c:2759 | Fapply eval.c:2255 | Ffuncall eval.c:2850 |
>>> funcall_lambda eval.c:3010 | exec_byte_code bytecode.c:900 | Ffuncall
>>> eval.c:2775 | Finput_pending_p keyboard.c:6687 | gobble_input
>>> keyboard.c:6768 | ns_read_socket nsterm.m:3424 | -[NSApplication run] |
>>> -[NSApplication _installMemoryStatusDispatchSources] |
>>> dispatch_source_create | _os_object_alloc_realized | class_createInstance
>>> |
>>> calloc | malloc_zone_calloc
>>> Leak: 0x1040efe20 size=160 zone: DefaultMallocZone_0x100630000
>>> OS_dispatch_source ObjC libdispatch.dylib
>>> 0x71162c20 0x00007fff 0x00000001 0x00000000 ,.q............
>>> 0x89abcdef 0xffffffff 0x71164480 0x00007fff .........D.q....
>>> 0x00000000 0x00000000 0x00000000 0x00000000 ................
>>> 0x00000000 0x00000000 0x00000000 0x00000000 ................
>>> 0x00000000 0x00000000 0x00000000 0x00000000 ................
>>> 0x00000001 0x00000000 0x00000175 0x00000000 ........u.......
>>> 0x8316090c 0x00007fff 0x00804760 0x00000001 ........`G......
>>> 0x040e2120 0x00000001 0x00000002 0x0000004c !..........L...
>>> ...
>>>
>>> The last line of code in emacs that produces this leak is:
>>>
>>> if (++apploopnr != 1)
>>> {
>>> emacs_abort ();
>>> }
>>> [NSApp run];
>>> --apploopnr;
>>>
>>> well it's the --apploopnr according to leaks! A little weird if you ask
>>> me.
>> The stack trace clearly states that it is in NSApp run (i.e. NSApplication
>> run), so the trace is off by one line. This happens often.
>>
>> Jan D.
>>
>>
>>
>>
>>
>>
>> ________________________________
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://emacs.1067599.n5.nabble.com/bug-15946-24-3-Mac-OS-X-Mavericks-distnoted-process-tp303500p310868.html
>> To unsubscribe from bug#15946: 24.3; Mac OS X, Mavericks, distnoted process,
>> click here.
>> NAML
>>
>>
>> Jonathan Payne
>>
>> ________________________________
>> View this message in context: Re: bug#15946: 24.3; Mac OS X, Mavericks,
>> distnoted process
>> Sent from the Emacs - Bugs mailing list archive at Nabble.com.
>
>

canoeberry

bug#15946: a patch against emacs 24.3.1 for fixing the distnoted memory leak

In reply to this post by Donald Tillman

Jonathan Payne

SB-6

bug#15946: a patch against emacs 24.3.1 for fixing the distnoted memory leak

Great detective work. I'd like to see the patch! ;)

Even if it's superseded by the next release (24.4), some people might
be stuck on 24.3 for whatever reason and right now this bug thread is
the best reference for information.

In the mean time, some more experienced people can look at the patch
and further isolate the relevant changes for a tighter patch or
confirm your work. People with the bug can build with your patch and
confirm whether this bug is fixed by it too.

On Mon, Jan 20, 2014 at 9:01 PM, Jonathan Payne <[hidden email]> wrote:

> This is FYI for people who do not want to wait for emacs 24.4 and cannot use one of the current nightlies to get around the Mavericks distnoted issue.
>
> I am not a Mac programmer unfortunately, so take this with a grain of salt. My analysis of the problem is this:
>
> 1) When Mavericks came out a memory leak was discovered and fixed by Jan D. who is a frequent contributor to ns (Next Step) emacs for Mac OS X.
>
> 2) His fix, I think, was to avoid calling Application.run 20 times / second by introducing a variable called "shouldKeepRunning" into the Application.run method.
>
> 3) Repeatedly calling Application.run was causing a 160 byte leak each time inside emacs. But I think it was also causing a problem with distnoted, and I am speculating (knowing NOTHING ABOUT IT) that each call to run() was causing some sort of registration with distnoted. That registration, I assume, creates some sort of context in distnoted that is substantially larger than 160 bytes. So the leak in emacs was relatively slow, the one in distnoted was much larger.
>
> This would also explain why distnoted would get slower as time goes by because it has hundreds of thousands of registrations, all for emacs, which I assume it was still trying to deliver notifications to, but really, I have no idea what I am talking about.
>
> So, I applied part of Jan D's patch to emacs-24.3 that addressed this particular problem, and presto-chango, the leak is gone, distnoted is happy, and all my current elisp packages work because it's still emacs-24.3 and not emacs-24.4 which I assume is what's being created in the trunk today.
>
> So - should I post this particular patch some place? Are other people interested in having this patch?
>
> JP
>
>
>
>

tony

Re: bug#15946: 24.3; Mac OS X, Mavericks, distnoted process

In reply to this post by Donald Tillman

On Monday, 25 November 2013 22:27:43 UTC, Marc Feeley wrote:
> Just want to add that I have the same problem. After quitting emacs
>
> the distnoted process quiets down to an acceptable level.

I upgraded to 24.4 to try to solve this problem but I've found recent nightly builds from http://emacsformacosx.com/, for example Emacs-2014-05-01_01-33-36-117037-universal-10.6.8.dmg, display the same memory leak behaviour (I'm on OS X 10.9.2).

An older build of 24.4 from January (Emacs-2014-01-25_01-34-03-116153-universal-10.6.8.dmg) seems fine though.

Lars Ingebrigtsen

bug#15946: 24.3; Mac OS X, Mavericks, distnoted process

In reply to this post by Jan D.-2

Jan Djärv <[hidden email]> writes:

> Hello.
>
> 20 jan 2014 kl. 10:53 skrev SB <[hidden email]>:
>
>> After reading reports in this thread that it was fixed in the trunk I
>> went and applied the aforementioned inline patch to the current trunk
>> and indeed the distnoted issue seems fixed. Whereas with my patch to
>> the inline patch the problem seemed a little more tolerable and still
>> required occasionally killing distnoted (and Emacs.app crashed
>> although less frequently).
>>
>> If there is a single commit that can make distnoted behave, it may be
>> in the interest of others using Mavericks to have this incorporated
>> into an official point release and close this bug (the distnoted bug
>> for those affected can be quite severe, locking up the entire machine
>> in my case). Mavericks is inevitable for many mac users and some
>> people may not be ready to transition to 24.4 for whatever reasons.
>
> There will not be any release for the 24.3 branch. 24.4 is next.
>
>>
>> The modified inline patch (only relevant if you use Japanese or some
>> other language for writing text in Emacs and want seamless language
>> switching while using various keys/commands) for the current trunk:
>>
>> https://gist.github.com/anonymous/8517045
>
> The patch is way too big to be incorporated into Emacs in the current feature freeze.

Is this still a problem on Mavericks with Emacs 25?

--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no

Alan Third

bug#15946: 24.3; Mac OS X, Mavericks, distnoted process

Lars Ingebrigtsen <[hidden email]> writes:

> Is this still a problem on Mavericks with Emacs 25?

No response in 29 weeks, I think we can close this one.
--
Alan Third

Donald Tillman

bug#15946: closed (Re: bug#15946: 24.3; Mac OS X, Mavericks, distnoted process)

In reply to this post by Donald Tillman

Yes, this was fixed long ago. I've been using the builds from emacsformacosx.com and the problem has not recurred.

And thanks, 'great job, it's appreciated.

-- Don

Don Tillman

Palo Alto, California

On Jul 17, 2016, at 1:58 PM, GNU bug Tracking System <[hidden email]> wrote:

Your bug report

#15946: 24.3; Mac OS X, Mavericks, distnoted process

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [hidden email].

--
15946: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15946
GNU Bug Tracking System
Contact [hidden email] with problems

From: Alan Third <[hidden email]>
Subject: Re: bug#15946: 24.3; Mac OS X, Mavericks, distnoted process
Date: July 17, 2016 at 1:57:34 PM PDT
To: Lars Ingebrigtsen <[hidden email]>
Cc: SB <[hidden email]>, Jan Djärv <[hidden email]>, [hidden email]

Lars Ingebrigtsen <[hidden email]> writes:

Is this still a problem on Mavericks with Emacs 25?

No response in 29 weeks, I think we can close this one.
--
Alan Third

From: Donald Tillman <[hidden email]>
Subject: 24.3; Mac OS X, Mavericks, distnoted process
Date: November 21, 2013 at 10:18:09 AM PST
To: [hidden email]

--text follows this line--
This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org. Please check that
the From: line contains a valid email address. After a delay of up
to one day, you should receive an acknowledgment at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug. If you can, give a recipe
starting from `emacs -Q':

----

Hi!

I use Emacs on Mac OS X, Mavericks, Intel MacBook Pro, downloaded from emacsformacosx.com.

Running Emacs, a process named "distnoted" starts around 1% or 2% of the CPU, and after a while, slowly works its way up to 50% to 100% of the CPU. Yoiks! Actually there appear to be 3 distnoted processes, but only one eats up the CPU.

Quitting Emacs brings distnoted down to under 1% within seconds.

-- Don

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/Applications/Emacs.app/Contents/Resources/etc/DEBUG.

In GNU Emacs 24.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.36)
of 2013-03-12 on bob.porkrind.org
Windowing system distributor `Apple', version 10.3.1265
Configured using:
`configure '--host=x86_64-apple-darwin' '--build=i686-apple-darwin'
'--with-ns' 'build_alias=i686-apple-darwin'
'host_alias=x86_64-apple-darwin' 'CC=gcc -mmacosx-version-min=10.7
-isystem
/Users/david/Xcode-10.7_4.5.2/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/include/
-F/Users/david/Xcode-10.7_4.5.2/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks''

Important settings:
locale-coding-system: nil
default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t

Recent input:
<help-echo> M-x r e p o r t SPC e m a <tab> <retur
n>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr warnings emacsbug message format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rainbow-mode-autoloads
svg-clock-autoloads package rmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel ns-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-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 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 ns multi-tty emacs)

--
Don Tillman
Palo Alto, California
[hidden email]
http://www.till.com