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

[canoeberry]

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

--
View this message in context: 
http://emacs.1067599.n5.nabble.com/bug-15946-24-3-Mac-OS-X-Mavericks-distnoted-process-tp303500p310818.html
Sent from the Emacs - Bugs mailing list archive at Nabble.com.