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

["Jan Djärv" <jan.h.d@swipnet.se>]

Hello.

18 jan 2014 kl. 23:52 skrev canoeberry <emacs@jpayne.net>:

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