bug#15946: 24.3; Mac OS X, Mavericks, distnoted process
Locked
12
12
bug#15946: 24.3; Mac OS X, Mavericks, distnoted process
 
|
--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 |
bug#15946: 24.3; Mac OS X, Mavericks, distnoted process
|
|
Just want to add that I have the same problem. After quitting emacs
the distnoted process quiets down to an acceptable level. |
|
|
In reply to this post by Donald Tillman
Hello.
I can not reproduce this. Does it happen when you start with -Q and then do nothing else? I tried with trunk and downloaded binaries from the site (release and latest). I ran them on two computers with 10.9. I once managed to get a distnoted process to use 1.2 percent CPU, but otherwise they where steady at 0 - 0.3 % no matter what I did in Emacs. I monitored the trunk build for a whole workday, about 8 hours. Jan D. > 21 nov 2013 kl. 19:18 skrev Donald Tillman <[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 > > > > > > |
bug#15946: 24.3; Mac OS X, Mavericks, distnoted process
|
|
In reply to this post by Donald Tillman
> I can not reproduce this.
I too have this problem. I'm not quite sure what triggers it, but it seems to to have something to do with command-tabbing (or at least that's what it feels like). If I can pinpoint it exactly I'll let it know. |
Re: bug#15946: 24.3; Mac OS X, Mavericks, distnoted process
|
|
In reply to this post by Jan D.-2
FYI I have the same problem too. It took me a while to connect it (likely) to emacs on mavericks, but it seems confirmed.
Setup: - late 2013 MPB 15" w/ discrete graphics card, CUDA installed - arrived installed with mavericks, did a migration from my 10.8 MBP, erased the emacs app, downloaded 24.3 from http://emacsformacosx.com - machine is up 8h/day mini always on, emacs 24.3 always on (used on an hourly basis) Symptom: - after a few days, distnoted start to be noticeable: 15%-25% CPU, system lagging, tens of thousands of threads active - rebooting the machine removes the problem for a few days - quitting and restarting emacs but no reboot also removes the problem for a few days I cannot conclude emacs is the cause of the problem, as I have tens of applications running, but there's an observable correlation. FYI the problem doesn't arrive in 8h but in a few days for me (2-3). I don't know yet if the speed of occurrence of the problem is connected with my emacs usage pattern, or from the number of hours emacs has been on. This is an important problem: it can end up making the system lagging, and does consume battery life. ++ On Wednesday, November 27, 2013 1:10:11 PM UTC-8, Piet Jaspers wrote: > > I can not reproduce this. > > > > I too have this problem. I'm not quite sure what triggers it, but it > > seems to to have something to do with command-tabbing (or at least > > that's what it feels like). > > > > If I can pinpoint it exactly I'll let it know. |
bug#15946: 24.3; Mac OS X, Mavericks, distnoted process
|
|
In reply to this post by Donald Tillman
Donald Tillman <don <at> till.com> writes:
> 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. Just wanted to bump this up, as I've now seen this bug myself. Not sure why Emacs is causing the problem. My emacs was built from macports. --Chris |
bug#15946: 24.3; Mac OS X, Mavericks, distnoted process
|
|
>>>>> On Mon, 9 Dec 2013 04:38:59 +0000 (UTC), Christopher Smith <[hidden email]> said:
> Donald Tillman <don <at> till.com> writes: >> 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. > Just wanted to bump this up, as I've now seen this bug myself. Not > sure why Emacs is causing the problem. My emacs was built from > macports. Which "port" did you use to build Emacs from MacPorts? I'm asking it because I'd like to know if this problem can also happen with Emacs Mac port(*). Users of the MacPorts package system can use it via the "port" named "emacs-mac-app" (its application bundle name is EmacsMac.app). *: http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00225.html YAMAMOTO Mitsuharu [hidden email] |
|
|
In reply to this post by Christopher Smith
Hello.
> 9 dec 2013 kl. 05:38 skrev Christopher Smith <[hidden email]>: > > Donald Tillman <don <at> till.com> writes: >> 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. > > Just wanted to bump this up, as I've now seen this bug myself. Not sure > why Emacs is causing the problem. My emacs was built from macports. It is no use bumping anything that isn't reproducable. More helpful would be if those that have this can do some debugging. For example dtruss on Emacs and distnoted. Jan D. |
|
|
Hello, I've investigated this problem since I had similar symptoms
that correlated with everyone else's reports (quit emacs.app and distnoted quiets down). Also, in my case when I download the vanilla emacs.app from the emacs for OSX site, the problem does not appear. In my case, under Mavericks, this problem only occurs when I use Emacs.app with the inline patch applied (for more native Japanese input). Emacs inline patch http://svn.sourceforge.jp/svnroot/macemacsjp/inline_patch/trunk/emacs-inline.patch After investigating, it seems that the purpose of distnoted is to serve as a daemon to facilitate interapplication communication. In the case of the "inline patch", to capture the moment the IME is changed so that Emacs can do likewise to change language input. This is done by adding an observer using NSDistributedNotificationCenter and there is also a corresponding Core Foundation method. I didn't find any used of NSDistributedNotificationCenter in the official release (24.3) source. https://developer.apple.com/library/mac/documentation/cocoa/reference/foundation/classes/NSDistributedNotificationCenter_Class/Reference/Reference.html The fix was to add "suspensionBehavior:NSNotificationSuspensionBehaviorDeliverImmediately" rather than the default which was "NSNotificationSuspensionBehaviorCoalesce". For whatever reason, modifying the inline patch in this manner fixed the issue for me. This would be consistent with the report above that "Cmd Tabbing" seems to trigger it (since it would activate the suspension behavior). Others with the same problem seem to take a sledgehammer approach of killing distnoted with a cronjob (which I did manually as well). This is the patch (modified by hand so it may not apply) against emacs 24.3. https://gist.github.com/anonymous/8142555 The modified line: [[NSDistributedNotificationCenter defaultCenter] addObserver: NSApp selector: @selector (changeInputMethod:) name: @"AppleSelectedInputSourcesChangedNotification" object: nil suspensionBehavior:NSNotificationSuspensionBehaviorDeliverImmediately]; Suspension Behavior https://developer.apple.com/library/mac/documentation/cocoa/reference/foundation/classes/NSDistributedNotificationCenter_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSNotificationSuspensionBehavior For others who do not use the patch, there may be other applications, since this is most likely a bug with Mavericks itself and you may want to log distnoted for additional hints and grep the source of your emacs build to see if NSDistributedNotificationCenter is being used. Logging Distnoted http://www.cocoawithlove.com/2009/02/interprocess-communication-snooping.html Hope this helps someone. Cheers, Sam On Mon, Dec 9, 2013 at 7:06 PM, Jan Djärv <[hidden email]> wrote: > Hello. > >> 9 dec 2013 kl. 05:38 skrev Christopher Smith <[hidden email]>: >> >> Donald Tillman <don <at> till.com> writes: >>> 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. >> >> Just wanted to bump this up, as I've now seen this bug myself. Not sure >> why Emacs is causing the problem. My emacs was built from macports. > > It is no use bumping anything that isn't reproducable. More helpful would be if those that have this can do some debugging. For example dtruss on Emacs and distnoted. > > Jan D. > > |
|
|
Hello.
This is good to know, but others said they used Emacs downloaded from emacsformacosx.com, which is supposed to be unpatched. So there might be more than one reason for this. Jan D. 27 dec 2013 kl. 06:15 skrev SB <[hidden email]>: > Hello, I've investigated this problem since I had similar symptoms > that correlated with everyone else's reports (quit emacs.app and > distnoted quiets down). Also, in my case when I download the vanilla > emacs.app from the emacs for OSX site, the problem does not appear. In > my case, under Mavericks, this problem only occurs when I use > Emacs.app with the inline patch applied (for more native Japanese > input). > > Emacs inline patch > http://svn.sourceforge.jp/svnroot/macemacsjp/inline_patch/trunk/emacs-inline.patch > > After investigating, it seems that the purpose of distnoted is to > serve as a daemon to facilitate interapplication communication. In the > case of the "inline patch", to capture the moment the IME is changed > so that Emacs can do likewise to change language input. This is done > by adding an observer using NSDistributedNotificationCenter and there > is also a corresponding Core Foundation method. I didn't find any used > of NSDistributedNotificationCenter in the official release (24.3) > source. > > https://developer.apple.com/library/mac/documentation/cocoa/reference/foundation/classes/NSDistributedNotificationCenter_Class/Reference/Reference.html > > The fix was to add > "suspensionBehavior:NSNotificationSuspensionBehaviorDeliverImmediately" > rather than the default which was > "NSNotificationSuspensionBehaviorCoalesce". For whatever reason, > modifying the inline patch in this manner fixed the issue for me. This > would be consistent with the report above that "Cmd Tabbing" seems to > trigger it (since it would activate the suspension behavior). > > Others with the same problem seem to take a sledgehammer approach of > killing distnoted with a cronjob (which I did manually as well). > > This is the patch (modified by hand so it may not apply) against emacs 24.3. > > https://gist.github.com/anonymous/8142555 > > The modified line: > > [[NSDistributedNotificationCenter defaultCenter] addObserver: NSApp > selector: @selector (changeInputMethod:) > name: > @"AppleSelectedInputSourcesChangedNotification" object: nil > suspensionBehavior:NSNotificationSuspensionBehaviorDeliverImmediately]; > > Suspension Behavior > https://developer.apple.com/library/mac/documentation/cocoa/reference/foundation/classes/NSDistributedNotificationCenter_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSNotificationSuspensionBehavior > > For others who do not use the patch, there may be other applications, > since this is most likely a bug with Mavericks itself and you may want > to log distnoted for additional hints and grep the source of your > emacs build to see if NSDistributedNotificationCenter is being used. > > Logging Distnoted > http://www.cocoawithlove.com/2009/02/interprocess-communication-snooping.html > > Hope this helps someone. > > Cheers, > > Sam > > On Mon, Dec 9, 2013 at 7:06 PM, Jan Djärv <[hidden email]> wrote: >> Hello. >> >>> 9 dec 2013 kl. 05:38 skrev Christopher Smith <[hidden email]>: >>> >>> Donald Tillman <don <at> till.com> writes: >>>> 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. >>> >>> Just wanted to bump this up, as I've now seen this bug myself. Not sure >>> why Emacs is causing the problem. My emacs was built from macports. >> >> It is no use bumping anything that isn't reproducable. More helpful would be if those that have this can do some debugging. For example dtruss on Emacs and distnoted. >> >> Jan D. >> >> |
|
|
On Tue, Jan 7, 2014 at 2:56 PM, Jan Djärv <[hidden email]> wrote:
> This is good to know, but others said they used Emacs downloaded from emacsformacosx.com, which is supposed to be unpatched. It does appear to be entirely unpatched, and the tools to produce it are publicly available[0] so it's easy to check. There's also an archive[1] of releases, pretests, and nightlies going back to 2006 (!) in .dmg format which is sometimes handy for bisection. [0] https://github.com/caldwell/build-emacs [1] http://emacsformacosx.com/builds/all |
|
|
Hello.
8 jan 2014 kl. 04:35 skrev Josh <[hidden email]>: > On Tue, Jan 7, 2014 at 2:56 PM, Jan Djärv <[hidden email]> wrote: >> This is good to know, but others said they used Emacs downloaded from emacsformacosx.com, which is supposed to be unpatched. > > It does appear to be entirely unpatched, and the tools to produce > it are publicly available[0] so it's easy to check. There's also > an archive[1] of releases, pretests, and nightlies going back to > 2006 (!) in .dmg format which is sometimes handy for bisection. > > [0] https://github.com/caldwell/build-emacs > [1] http://emacsformacosx.com/builds/all This has to be done by someone who has the problem. I already tried several of their builds, on three separate machines. None exhibit the problem. Jan D. |
Re: bug#15946: 24.3; Mac OS X, Mavericks, distnoted process
|
|
In reply to this post by Donald Tillman
I have been observing this since Mavericks was released. I did not make a connection between distnoted and emacs, other than the following observation: both are leaking memory.
For the first time ever I am finding that my emacs process slowly grows in size. I can be editing a small handful of files and be using 500Mb of real memory. Never seen that before, ever. Distnoted grows much faster, on the order of 1Gb real memory / day. Killing that process and having another start up automatically causes some OS X features to stop working, e.g., it is not possible to enter Time Machine or even see the status of your Time Machine backups anymore. I have seen distnoted peg the CPU when Time Machine backups are running or recently completed. Meanwhile, the menubar no longer animates the in-progress backup, which I assume is not on purpose and possibly even related to the issue. I do not use shells in emacs nowadays. I am running emacs from emacsformacosx. I have filed bugs with Apple. If anybody has any suggestions on how to figure out what is causing Emacs to grow in size, I will happily run some experiments for you. I tried to figure out how to profile emacs memory but it was not very obvious to me what to do.
Jonathan Payne
|
|
|
Hello.
14 jan 2014 kl. 18:15 skrev canoeberry <[hidden email]>: > I have been observing this since Mavericks was released. I did not make a > connection between distnoted and emacs, other than the following > observation: both are leaking memory. > > For the first time ever I am finding that my emacs process slowly grows in > size. I can be editing a small handful of files and be using 500Mb of real > memory. Never seen that before, ever. > > Distnoted grows much faster, on the order of 1Gb real memory / day. Killing > that process and having another start up automatically causes some OS X > features to stop working, e.g., it is not possible to enter Time Machine or > even see the status of your Time Machine backups anymore. > > I have seen distnoted peg the CPU when Time Machine backups are running or > recently completed. Meanwhile, the menubar no longer animates the > in-progress backup, which I assume is not on purpose and possibly even > related to the issue. > I think that is so OSX can save a bit of power. > I do not use shells in emacs nowadays. > > I am running emacs from emacsformacosx. > > I have filed bugs with Apple. > > If anybody has any suggestions on how to figure out what is causing Emacs to > grow in size, I will happily run some experiments for you. I tried to figure > out how to profile emacs memory but it was not very obvious to me what to > do. The obvious thing is to run leaks on Emacs (man leaks) after a garbage collection has been made (M-x garbage-collect). Leaks may report leaks which in fact are not due to uncollected garbage. Jan D. |
Re: bug#15946: 24.3; Mac OS X, Mavericks, distnoted process
|
|
This is what I see if I run the "leaks" program on my Mac on the emacs process:
Leak: 0x1109f7b20 size=160 zone: DefaultMallocZone_0x100659000 OS_dispatch_source ObjC libdispatch.dylib 0x76964c20 0x00007fff 0x00000001 0x00000000 L.v............ 0x89abcdef 0xffffffff 0x769666c0 0x00007fff .........f.v.... 0x00000000 0x00000000 0x00000000 0x00000000 ................ 0x00000000 0x00000000 0x00000000 0x00000000 ................ 0x00000000 0x00000000 0x00000000 0x00000000 ................ 0x00000001 0x00000000 0x0002940d 0x00000000 ................ 0x8896290c 0x00007fff 0x013000a0 0x00000001 .)........0..... 0x109f7c10 0x00000001 0x00000002 0x0000004c .|..........L... ... A bazillion of them. I also ran it on a distnoted which I just killed and restarted because the existing one was over 2Gb of real memory (or so it said). It claimed there were no leaks. This leaks program is pretty cool. It's like a conservative GC algorithm that assumes every integer could be a pointer. So by definition is is conservative. Anyway - does this piece of information help any smart hacker types? JP On 14 Jan 2014, at 17:47, Jan Djärv [via Emacs] <[hidden email]> wrote: Hello.
Jonathan Payne
|
Re: bug#15946: 24.3; Mac OS X, Mavericks, distnoted process
|
|
In reply to this post by Jan D.-2
I've fired up Emacs with the -q and -nsl options. So my .emacs is not loaded and neither is the site-lisp. It starts leaking memory at a rate ... well here you go:
$ while true
> do > sudo leaks 12095 | head -20 | grep "leaks for" > sleep 1 > done Process 12095: 935 leaks for 165824 total leaked bytes. Process 12095: 954 leaks for 168864 total leaked bytes. Process 12095: 972 leaks for 171744 total leaked bytes. Process 12095: 986 leaks for 173984 total leaked bytes. Process 12095: 1005 leaks for 177024 total leaked bytes. Process 12095: 1025 leaks for 180224 total leaked bytes. Process 12095: 1039 leaks for 182464 total leaked bytes. Process 12095: 1057 leaks for 185344 total leaked bytes. Process 12095: 1076 leaks for 188384 total leaked bytes. Process 12095: 1090 leaks for 190624 total leaked bytes. Process 12095: 1107 leaks for 193344 total leaked bytes. Process 12095: 1127 leaks for 196544 total leaked bytes. Process 12095: 1147 leaks for 199744 total leaked bytes. Process 12095: 1158 leaks for 201504 total leaked bytes. Process 12095: 1178 leaks for 204704 total leaked bytes. Process 12095: 1195 leaks for 207424 total leaked bytes. Process 12095: 1209 leaks for 209664 total leaked bytes. So it's basically something like 20 individual 160 byte leaks per second. If I actually use emacs it seems to have spurts of many more leaks. These do seem like proper leaks because my emacs memory is growing at the same rate as this leaks is reporting, and, I am literally running an emacs with nothing in it and not interacting with it. Output from dtruss shows kevent activity. A bunch of it. Not much else: workq_kernreturn(0x20, 0x0, 0x1) = 0 0 kevent64(0x3, 0x0, 0x0) = 1 0 kevent64(0x3, 0x1006CB458, 0x1) = 1 0 kevent64(0x3, 0x1006CB458, 0x1) = 1 0 kevent64(0x3, 0x0, 0x0) = 1 0 kevent64(0x3, 0x1006CB4F8, 0x1) = 1 0 kevent64(0x3, 0x0, 0x0) = 1 0 kevent64(0x3, 0x0, 0x0) = 1 0 kevent64(0x3, 0x1006CB458, 0x1) = 1 0 kevent64(0x3, 0x1006CB458, 0x1) = 1 0 kevent64(0x3, 0x0, 0x0) = 1 0 kevent64(0x3, 0x1006CB3E8, 0x1) = 1 0 kevent64(0x3, 0x1006CB4F8, 0x1) = 1 0 kevent64(0x3, 0x0, 0x0) = 1 0 kevent64(0x3, 0x0, 0x0) = 1 0 kevent64(0x3, 0x1006CB458, 0x1) = 1 0 kevent64(0x3, 0x1006CB458, 0x1) = 1 0 kevent64(0x3, 0x7FFF5FBFD2E8, 0x1) = 1 0 kevent64(0x3, 0x0, 0x0) = 1 0 kevent64(0x3, 0x1006CB458, 0x1) = 1 0 kevent64(0x3, 0x1006CB458, 0x1) = 1 0 kevent64(0x3, 0x7FFF5FBFE8B8, 0x1) = 1 0 workq_kernreturn(0x20, 0x0, 0x1) = 0 0 kevent64(0x3, 0x7FFF5FBFCAF8, 0x1) = 1 0 kevent64(0x3, 0x0, 0x0) = 1 0 kevent64(0x3, 0x1006CB458, 0x1) = 1 0 kevent64(0x3, 0x1006CB458, 0x1) = 1 0 kevent64(0x3, 0x0, 0x0) = 1 0 kevent64(0x3, 0x1006CB458, 0x1) = 1 0 kevent64(0x3, 0x1006CB458, 0x1) = 1 0 setitimer(0x0, 0x7FFF5FBFD0B0, 0x0) = 0 0 kevent64(0x3, 0x7FFF5FBFE8C8, 0x1) = 1 0 workq_kernreturn(0x20, 0x0, 0x1) = 0 0 workq_kernreturn(0x20, 0x0, 0x1) = 0 0 This is grasping at straws at its worst. JP On 14 Jan 2014, at 17:47, Jan Djärv [via Emacs] <[hidden email]> wrote: Hello.
Jonathan Payne
|
bug#15946: 24.3; Mac OS X, Mavericks, distnoted process
|
|
In reply to this post by canoeberry
> If anybody has any suggestions on how to figure out what is causing Emacs to
> grow in size, It'd be useful to state precisely which Emacs you're running. Stefan |
Re: bug#15946: 24.3; Mac OS X, Mavericks, distnoted process
|
|
Sorry about that!
GNU Emacs 24.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2013-03-13 on bob.porkrind.org From emacsformacos.com. I think I was already using this version before I upgraded to Mavericks and it was sometime after the Mavericks upgrade that I noticed the leak. So it's ... likely an incompatible change or just a bug in Mavericks. JP
On 14 Jan 2014, at 21:36, Stefan Monnier [via Emacs] <[hidden email]> wrote: > If anybody has any suggestions on how to figure out what is causing Emacs to
Jonathan Payne
|
|
|
Hello.
14 jan 2014 kl. 22:53 skrev canoeberry <[hidden email]>: Sorry about that! Jan D.
|
|
|
In reply to this post by canoeberry
Hello.
14 jan 2014 kl. 21:09 skrev canoeberry <[hidden email]>: > This is what I see if I run the "leaks" program on my Mac on the emacs process: > > Leak: 0x1109f7b20 size=160 zone: DefaultMallocZone_0x100659000 OS_dispatch_source ObjC libdispatch.dylib > 0x76964c20 0x00007fff 0x00000001 0x00000000 L.v............ > 0x89abcdef 0xffffffff 0x769666c0 0x00007fff .........f.v.... > 0x00000000 0x00000000 0x00000000 0x00000000 ................ > 0x00000000 0x00000000 0x00000000 0x00000000 ................ > 0x00000000 0x00000000 0x00000000 0x00000000 ................ > 0x00000001 0x00000000 0x0002940d 0x00000000 ................ > 0x8896290c 0x00007fff 0x013000a0 0x00000001 .)........0..... > 0x109f7c10 0x00000001 0x00000002 0x0000004c .|..........L... > ... > > A bazillion of them. > > I also ran it on a distnoted which I just killed and restarted because the existing one was over 2Gb of real memory (or so it said). It claimed there were no leaks. > > This leaks program is pretty cool. It's like a conservative GC algorithm that assumes every integer could be a pointer. So by definition is is conservative. > > Anyway - does this piece of information help any smart hacker types? 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. Jan D. |
«
Return to Emacs - Bugs
|
1 view|%1 views
| Free forum by Nabble | Edit this page |