bug#15946: 24.3; Mac OS X, Mavericks, distnoted process
Locked
12
12
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" |
|
|
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. |
|
|
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. |
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 |
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:
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. JP On 15 Jan 2014, at 06:26, Jan Djärv <[hidden email]> wrote: Hi.
Jonathan Payne
|
|
|
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 |
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
|
|
|
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. |
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.
Jonathan Payne
|
|
|
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. |
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 |
|
|
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. > > |
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
Jonathan Payne
|
|
|
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 > > > > |
|
|
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. |
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 |
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 |
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
|
«
Return to Emacs - Bugs
|
1 view|%1 views
| Free forum by Nabble | Edit this page |