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

[SB]

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 <emacs@jpayne.net> 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&amp;node=310868&amp;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.