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

[Jan Djärv]

Hello.

20 jan 2014 kl. 10:53 skrev SB <richstyles@gmail.com>:

> 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 <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.
> 
>