* Re: Memory again
@ 2011-12-20 6:34 emacs user
2011-12-20 7:43 ` Eli Zaretskii
0 siblings, 1 reply; 87+ messages in thread
From: emacs user @ 2011-12-20 6:34 UTC (permalink / raw)
To: emacs-devel
> From: Dmitry Antipov
>
> For whatever it's worth, I need to kill my emacs (GNU Emacs 24.0.92.1
> x86_64-apple-darwin11.2.0, NS apple-appkit-1138.23) several times a
> day when it reached over 300mb or it will crash. This memory usage is
> *after* I kill all buffers and do M-x garbage collect. I submitted a
> couple of bug reports, please see
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-12/msg00404.html
> am happy to do additional tests if anyone could guide me.
>
> I'm not an expert in Apple world, but the first step looks almost obvious -
> can you try to use 'leaks' (for example, see http://shorestreet.com/node/4)
> and see whether it shows something useful?
>
> Dmitry
>
thanks! here it is. I attach both the leaks output, and the
backtrace/ xbacktrace for a crash that happens eventually.
At the time of this leaks report, emacs has 192Mb according to the
activity monitor, with all buffers deleted. happy to do additional
tests if needed.
------------------------------------------------------------------------
$ leaks 32883
Process: Emacs [32883]
Path: /usr/local/emacs/trunk/nextstep/Emacs.app/Contents/MacOS/Emacs
Load Address: 0x100000000
Identifier: org.gnu.Emacs
Version: Version 24.0.91 (9.0)
Code Type: X86-64 (Native)
Parent Process: launchd [140]
Date/Time: 2011-12-20 01:26:33.878 -0500
OS Version: Mac OS X 10.7.2 (11C74)
Report Version: 7
leaks Report Version: 2.0
Process 32883: 340763 nodes malloced for 85315 KB
Process 32883: 141 leaks for 8592 total leaked bytes.
Leak: 0x106f89eb0 size=544 zone: DefaultMallocZone_0x100a63000
__NSCFString ObjC CoreFoundation
0x788d1ae8 0x00007fff 0x00000790 0x00000001 ...x............
0x00000100 0x00000000 0x00010000 0x00030002 ................
0x00050004 0x00070006 0x00090008 0x000b000a ................
0x000d000c 0x000f000e 0x00110010 0x00130012 ................
0x00150014 0x00170016 0x00190018 0x001b001a ................
0x001d001c 0x001f001e 0x00210020 0x00230022 ........ .!.".#.
0x00250024 0x00270026 0x00290028 0x002b002a $.%.&.'.(.).*.+.
0x002d002c 0x002f002e 0x00310030 0x00330032 ,.-.../.0.1.2.3.
...
Leak: 0x107454320 size=544 zone: DefaultMallocZone_0x100a63000
__NSCFString ObjC CoreFoundation
0x788d1ae8 0x00007fff 0x00000790 0x00000001 ...x............
0x00000100 0x00000000 0x00010000 0x00030002 ................
0x00050004 0x00070006 0x00090008 0x000b000a ................
0x000d000c 0x000f000e 0x00110010 0x00130012 ................
0x00150014 0x00170016 0x00190018 0x001b001a ................
0x001d001c 0x001f001e 0x00210020 0x00230022 ........ .!.".#.
0x00250024 0x00270026 0x00290028 0x002b002a $.%.&.'.(.).*.+.
0x002d002c 0x002f002e 0x00310030 0x00330032 ,.-.../.0.1.2.3.
...
Leak: 0x108018630 size=544 zone: DefaultMallocZone_0x100a63000
__NSCFString ObjC CoreFoundation
0x788d1ae8 0x00007fff 0x00000790 0x00000001 ...x............
0x00000100 0x00000000 0x00010000 0x00030002 ................
0x00050004 0x00070006 0x00090008 0x000b000a ................
0x000d000c 0x000f000e 0x00110010 0x00130012 ................
0x00150014 0x00170016 0x00190018 0x001b001a ................
0x001d001c 0x001f001e 0x00210020 0x00230022 ........ .!.".#.
0x00250024 0x00270026 0x00290028 0x002b002a $.%.&.'.(.).*.+.
0x002d002c 0x002f002e 0x00310030 0x00330032 ,.-.../.0.1.2.3.
...
Leak: 0x106850160 size=80 zone: DefaultMallocZone_0x100a63000
NSCTFontDescriptor ObjC AppKit
0x792a8c40 0x00007fff 0x00011d80 0x00000001 @.*y............
0x00000000 0x00000000 0x8b7fbdee 0x00007fff ................
0x00000000 0x00000000 0x06850190 0x00000001 ................
0x787d4a60 0x00007fff 0x0684ffd0 0x00000001 `J}x............
0x80000000 0x00000000 0x00fe26f0 0x00000001 .........&......
Leak: 0x106878ed0 size=80 zone: DefaultMallocZone_0x100a63000
NSCTFontDescriptor ObjC AppKit
0x792a8c40 0x00007fff 0x00011d80 0x00000001 @.*y............
0x00000000 0x00000000 0x8b7fbdee 0x00007fff ................
0x00000000 0x00000000 0x06878f00 0x00000001 ................
0x787d4a60 0x00007fff 0x06878dc0 0x00000001 `J}x............
0x80000000 0x00000000 0x00fe26f0 0x00000001 .........&......
Leak: 0x106f8a0d0 size=80 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000100 0x00000000 ................
0x00000000 0x00000000 0x00000001 0x00000001 ................
0x00000002 0x00000000 0x00000100 0x00000000 ................
0x06f8a120 0x00000001 0x00000000 0x00000000 ...............
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x1071aa7f0 size=80 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000100 0x00000000 ................
0x00000000 0x00000000 0x00000001 0x00000001 ................
0x00000002 0x00000000 0x00000100 0x00000000 ................
0x07247ec0 0x00000001 0x00000000 0x00000000 .~$.............
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x1073592f0 size=80 zone: DefaultMallocZone_0x100a63000
_NSImageAuxiliary ObjC AppKit
0x792a99b0 0x00007fff 0x06865800 0x00000001 ..*y.....X......
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x3ff00000 ...............?
0x00000000 0x3ff00000 0x00000000 0x00000000 .......?........
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x107362530 size=80 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000100 0x00000000 ................
0x00000000 0x00000000 0x00000001 0x00000001 ................
0x00000002 0x00000000 0x00000100 0x00000000 ................
0x08018040 0x00000001 0x00000000 0x00000000 @...............
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x1073786b0 size=80 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x001ca331 0x00000001 ........1.......
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x0180303a 0x00000001 ........:0......
0x00000001 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x1073ad730 size=80 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x001ca331 0x00000001 ........1.......
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x0180303a 0x00000001 ........:0......
0x00000001 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x100d87150 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x100fe30d0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x100fe3110 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x10684fa20 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x10684fa60 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x106878a40 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x106878a80 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x106879330 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x106879370 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x106879da0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x106897f50 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x106897f90 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x106898760 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x1068987a0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x106f84700 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x106f85430 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x106f86c30 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x106f8a420 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x106fb1320 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x106fca680 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x10713be00 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x1071b10b0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x107359280 size=64 zone: DefaultMallocZone_0x100a63000
NSImage ObjC AppKit
0x792a9870 0x00007fff 0x00000000 0x00000000 p.*y............
0x00000000 0x40400000 0x00000000 0x40400000 ......@@......@@
0x00000189 0x00000000 0x07359340 0x00000001 ........@.5.....
0x073592f0 0x00000001 0x00000000 0x00000000 ..5.............
Leak: 0x107361460 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x10737ab70 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x10737b740 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x10738b7e0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x10738b820 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x10738d530 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x107392920 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x107394c30 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x1073f5660 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x1073f56a0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x1073f6190 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x1073f61d0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x1074663e0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x1074a1650 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x1074a89a0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x1074a89e0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x1074ac570 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x1074ad000 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x1074afc80 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x1074fa1b0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x108009630 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x108009670 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x108009eb0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x108009ef0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x10800a270 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x10800ae00 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x108066470 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x108067f20 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x108067f60 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x108070b80 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x10807abc0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x108447d20 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x10e383fd0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x10e9e54e0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x10ebd97f0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x10ebd9830 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x10ece2c70 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x10ece30a0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Leak: 0x10ed03dd0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x10ed03e10 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x10ed072e0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x10ed07320 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x10ed0af70 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x10ed0afb0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x11194cb70 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Leak: 0x100d18560 size=48 zone: DefaultMallocZone_0x100a63000
NSAutoreleasePool ObjC Foundation
0x78cceaf8 0x00007fff 0x02841038 0x00000001 ...x....8.......
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x100d92720 size=48 zone: DefaultMallocZone_0x100a63000
__NSCFCharacterSet ObjC CoreFoundation
0x788d1c78 0x00007fff 0x000019b1 0x00000001 x..x............
0x00000000 0x00000000 0x0289f000 0x00000001 ................
0x0000007f 0x00000000 0x00000000 0x00000000 ................
Leak: 0x100d4cad0 size=32 zone: DefaultMallocZone_0x100a63000
__NSCFNumber ObjC CoreFoundation value: 1
Leak: 0x100f28ec0 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x08070b80 0x00000001 ................
0x00000000 0x00000000 0x00000000 0x00020000 ................
Leak: 0x106879e80 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x06879de0 0x00000001 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x106879ea0 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x792cf120 0x00007fff ........ .,y....
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x106f89d80 size=32 zone: DefaultMallocZone_0x100a63000
NSConcreteAttributedString ObjC Foundation
0x78cce968 0x00007fff 0x06f89eb0 0x00000001 h..x............
0x06f84160 0x00000001 0x00000000 0x00000000 `A..............
Leak: 0x106fc4940 size=32 zone: DefaultMallocZone_0x100a63000
__NSCFNumber ObjC CoreFoundation value: 1
Leak: 0x1071117a0 size=32 zone: DefaultMallocZone_0x100a63000
NSConcreteAttributedString ObjC Foundation
0x78cce968 0x00007fff 0x07454320 0x00000001 h..x.... CE.....
0x0727dbd0 0x00000001 0x00000000 0x00000000 ..'.............
Leak: 0x107127470 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x074663e0 0x00000001 .........cF.....
0x00000000 0x00000000 0x00000001 0x00020000 ................
Leak: 0x107297890 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x792cf120 0x00007fff ........ .,y....
0x00000000 0x00000000 0x00696c65 0x00020000 ........eli.....
Leak: 0x107359340 size=32 zone: DefaultMallocZone_0x100a63000
NSImageIconRefRepProvider ObjC AppKit
0x792a98c0 0x00007fff 0x00000001 0x00000000 ..*y............
0x00000001 0x00000000 0x00000000 0x00000000 ................
Leak: 0x107375ba0 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x792cf1a0 0x00007fff 0x00000001 0x00020000 ..,y............
Leak: 0x1073878f0 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x08098330 0x00000001 0x0806c6d0 0x00020001 0...............
Leak: 0x107390e60 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x06fc4940 0x00000001 0x106fabe3 0x00020000 @I........o.....
Leak: 0x1073a2250 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x792cf120 0x00007fff ........ .,y....
0x00000000 0x00000000 0x788ed6a0 0x00027fff ...........x....
Leak: 0x1073a85a0 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x0737b740 0x00000001 ........@.7.....
0x00000000 0x00000000 0x0180303a 0x00020001 ........:0......
Leak: 0x1073f57c0 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x073f5a30 0x00000001 ........0Z?.....
0x00000000 0x00000000 0x00000000 0x00020000 ................
Leak: 0x1073f5a30 size=32 zone: DefaultMallocZone_0x100a63000
__NSCFNumber ObjC CoreFoundation value: 1
Leak: 0x1073f6210 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x792cf1e0 0x00007fff ..........,y....
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x1073f6230 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x073f61d0 0x00000001 .........a?.....
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x1073f6250 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x792cf120 0x00007fff ........ .,y....
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x107447690 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x792cf1a0 0x00007fff 0x08515dd0 0x00020001 ..,y.....]Q.....
Leak: 0x10747a960 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x792cf1a0 0x00007fff 0x00000001 0x00020000 ..,y............
Leak: 0x10748ce30 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x0ed06940 0x00000001 0x00000000 0x00000000 @i..............
Leak: 0x10748ce50 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x792cf1a0 0x00007fff 0x08074610 0x00000001 ..,y.....F......
Leak: 0x10748ce70 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x0ed03e10 0x00000001 .........>......
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x10748ce90 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x792cf120 0x00007fff ........ .,y....
0x00000000 0x00000000 0x0806a610 0x00000001 ................
Leak: 0x107499d90 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00d4cad0 0x00000001 0x00000001 0x00020000 ................
Leak: 0x10749d980 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x792cf120 0x00007fff ........ .,y....
0x00000000 0x00000000 0x788e9320 0x00027fff ........ ..x....
Leak: 0x1074a0c20 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x792cf120 0x00007fff ........ .,y....
0x00000000 0x00000000 0x00000000 0x00020000 ................
Leak: 0x108014650 size=32 zone: DefaultMallocZone_0x100a63000
NSConcreteAttributedString ObjC Foundation
0x78cce968 0x00007fff 0x08018630 0x00000001 h..x....0.......
0x08014670 0x00000001 0x00000000 0x00000000 pF..............
Leak: 0x108041560 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x792cf1a0 0x00007fff 0x00000001 0x00020000 ..,y............
Leak: 0x108077dc0 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x0e9b4170 0x00000001 0x00696c65 0x00020000 pA......eli.....
Leak: 0x10808ac60 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x08447d20 0x00000001 ........ }D.....
0x00000000 0x00000000 0x90090901 0x00027fff ................
Leak: 0x108098330 size=32 zone: DefaultMallocZone_0x100a63000
__NSCFNumber ObjC CoreFoundation value: 1
Leak: 0x1080df170 size=32 zone: DefaultMallocZone_0x100a63000
__NSCFNumber ObjC CoreFoundation value: 1
Leak: 0x1080f0b50 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x080df170 0x00000001 0x00000001 0x00020000 p...............
Leak: 0x10850ec70 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x792cf120 0x00007fff ........ .,y....
0x00000000 0x00000000 0x00000000 0x00020000 ................
Leak: 0x10851e690 size=32 zone: DefaultMallocZone_0x100a63000
__NSCFNumber ObjC CoreFoundation value: 1
Leak: 0x10853d090 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x792cf1a0 0x00007fff 0x00000000 0x00020000 ..,y............
Leak: 0x10855dad0 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x0851e690 0x00000001 0x73616573 0x00020203 ..Q.....seas....
Leak: 0x10ac7e9c0 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x792cf120 0x00007fff ........ .,y....
0x00000000 0x00000000 0x0e3ec6d0 0x00020001 ..........>.....
Leak: 0x10e9b4170 size=32 zone: DefaultMallocZone_0x100a63000
__NSCFNumber ObjC CoreFoundation value: 1
Leak: 0x10e9c39f0 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x792cf1a0 0x00007fff 0x073b0900 0x00020001 ..,y......;.....
Leak: 0x10eafc060 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x0ebd9830 0x00000001 ........0.......
0x00000000 0x00000000 0x00000000 0x00020000 ................
Leak: 0x10ece5c60 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x074a1650 0x00000001 ........P.J.....
0x00000000 0x00000000 0x00000000 0x00020007 ................
Leak: 0x10ed06940 size=32 zone: DefaultMallocZone_0x100a63000
__NSCFNumber ObjC CoreFoundation value: 1
Leak: 0x10ed06fe0 size=32 zone: DefaultMallocZone_0x100a63000
__NSCFNumber ObjC CoreFoundation value: 1
Leak: 0x10ed07000 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x0ed06fe0 0x00000001 .........o......
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x10ed07360 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x792cf1e0 0x00007fff ..........,y....
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x10ed07380 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x0ed07320 0x00000001 ........ s......
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x10ed073a0 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x792cf120 0x00007fff ........ .,y....
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x10ed0ac20 size=32 zone: DefaultMallocZone_0x100a63000
__NSCFNumber ObjC CoreFoundation value: 1
Leak: 0x10ed0ac40 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x0ed0ac20 0x00000001 0x0ea1de23 0x00000001 .......#.......
Leak: 0x10ed0aff0 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x792cf1a0 0x00007fff 0x00000000 0x00000000 ..,y............
Leak: 0x10ed0b010 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x0ed0afb0 0x00000001 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x10ed0b030 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x792cf120 0x00007fff ........ .,y....
0x00000000 0x00000000 0x00000000 0x00000000 ................
Leak: 0x10ee14790 size=32 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x0e383fd0 0x00000001 .........?8.....
0x00000000 0x00000000 0x00000000 0x00020000 ................
Leak: 0x106f84160 size=16 zone: DefaultMallocZone_0x100a63000
NSMutableRLEArray ObjC Foundation
0x78ccea08 0x00007fff 0x06f8a0d0 0x00000001 ...x............
Leak: 0x10727dbd0 size=16 zone: DefaultMallocZone_0x100a63000
NSMutableRLEArray ObjC Foundation
0x78ccea08 0x00007fff 0x071aa7f0 0x00000001 ...x............
Leak: 0x108014670 size=16 zone: DefaultMallocZone_0x100a63000
NSMutableRLEArray ObjC Foundation
0x78ccea08 0x00007fff 0x07362530 0x00000001 ...x....0%6.....
eli@udp003017uds:~ $
------------------------------------------------------------------------
/usr/local/emacs/trunk $ cd
src/eli@udp003017uds:/usr/local/emacs/trunk/src $ gdb -r
../nextstep/Emacs.app/Contents/MacOS/Emacs
GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul 1 10:50:06 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for
shared libraries ............ done
DISPLAY = /tmp/launch-lMLpCM/org.x:0
TERM = xterm-256color
Function "abort" not defined.
Breakpoint 1 at 0x1000be5de: file sysdep.c, line 854.
(gdb) run
Starting program:
/usr/local/emacs/trunk/nextstep/Emacs.app/Contents/MacOS/Emacs
Reading symbols for shared libraries
+++++++++++.................................................................................................................................
done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
mark_object () at alloc.c:5587
5587 if (ptr->gcmarkbit)
(gdb) xbacktrace
"byte-code" (0x5fbfd850)
"byte-code" (0x5fbfdb10)
"vm-read-index-file" (0x5fbfde58)
"byte-code" (0x5fbfdf10)
"vm-read-index-file-maybe" (0x5fbfe258)
"byte-code" (0x5fbfe340)
"vm" (0x5fbfe650)
"vm-my-open-folder-RMAIL" (0x5fbfe8b0)
"call-interactively" (0x5fbfeaa8)
(gdb) backtrace
#0 mark_object () at alloc.c:5587
#1 0x00000001000fdb60 in mark_object () at alloc.c:5595
#2 0x00000001000fdb0a in mark_object () at alloc.c:5592
#3 0x00000001000fdb01 in mark_object () at alloc.c:5591
#4 0x00000001000fdad8 in mark_vectorlike [inlined] () at
/usr/local/emacs/trunk/src/alloc.c:5391
#5 0x00000001000fdad8 in mark_object () at alloc.c:5579
#6 0x0000000100101f6b in Fgarbage_collect () at alloc.c:5099
#7 0x000000010011ac96 in Ffuncall (nargs=282508048478266,
args=0x7fff5fbfd710) at eval.c:2923
#8 0x0000000100155195 in exec_byte_code (bytestr=4296006374,
vector=4414034432, maxdepth=140734799795984, args_template=4320145466,
nargs=140734799795976, args=0x103706ddc) at bytecode.c:785
#9 0x000000010011cd57 in eval_sub (form=4296133950) at eval.c:2340
#10 0x000000010011ea6a in internal_lisp_condition_case
(var=4324704794, bodyform=4351855830, handlers=4352102646) at
eval.c:1453
#11 0x000000010015585f in exec_byte_code (bytestr=4296006374,
vector=4413818352, maxdepth=140734799796832, args_template=4320145466,
nargs=0, args=0x0) at bytecode.c:981
#12 0x000000010011cd57 in eval_sub (form=4296133950) at eval.c:2340
#13 0x000000010011e828 in internal_catch (tag=4324704794,
func=0x10011c6e0 <eval_sub>, arg=4324704794) at eval.c:1256
#14 0x000000010015582e in exec_byte_code (bytestr=4296006374,
vector=4413561360, maxdepth=140734799797480, args_template=4320145466,
nargs=0, args=0x0) at bytecode.c:966
#15 0x000000010011db0a in funcall_lambda (fun=140734799797696,
nargs=140734799797696, arg_vector=0x7fff5fbfddc0) at eval.c:3217
#16 0x000000010011b034 in Ffuncall (nargs=4320500586,
args=0x103693332) at eval.c:3035
#17 0x0000000100155195 in exec_byte_code (bytestr=4296006374,
vector=4414034304, maxdepth=140734799797840, args_template=4320145466,
nargs=140734799797832, args=0x0) at bytecode.c:785
#18 0x000000010011cd57 in eval_sub (form=4296133950) at eval.c:2340
#19 0x000000010011e828 in internal_catch (tag=2, func=0x10011c6e0
<eval_sub>, arg=2) at eval.c:1256
#20 0x000000010015582e in exec_byte_code (bytestr=4296006374,
vector=4413812688, maxdepth=140734799798504, args_template=4320145466,
nargs=0, args=0x0) at bytecode.c:966
#21 0x000000010011db0a in funcall_lambda (fun=140734799798720,
nargs=140734799798720, arg_vector=0x7fff5fbfe1c0) at eval.c:3217
#22 0x000000010011b034 in Ffuncall (nargs=4320500586,
args=0x1034f52f2) at eval.c:3035
#23 0x0000000100155195 in exec_byte_code (bytestr=4296006374,
vector=4350499328, maxdepth=140734799798864, args_template=4320145466,
nargs=140734799798856, args=0x22b) at bytecode.c:785
#24 0x000000010011cd57 in eval_sub (form=4296133950) at eval.c:2340
#25 0x000000010011e828 in internal_catch (tag=1, func=0x10011c6e0
<eval_sub>, arg=1) at eval.c:1256
#26 0x000000010015582e in exec_byte_code (bytestr=4296006374,
vector=4412514528, maxdepth=140734799799576, args_template=4320145466,
nargs=140734799799560, args=0x10352313c) at bytecode.c:966
#27 0x000000010011db0a in funcall_lambda (fun=140734799799872,
nargs=140734799799872, arg_vector=0x7fff5fbfe640) at eval.c:3217
#28 0x000000010011d272 in apply_lambda (fun=140734799799984, args=1)
at eval.c:3094
#29 0x000000010011ce77 in eval_sub (form=5) at eval.c:2379
#30 0x000000010011dabc in Fprogn [inlined] () at
/usr/local/emacs/trunk/src/eval.c:358
#31 0x000000010011dabc in funcall_lambda (fun=140734799800320,
nargs=140734799800320, arg_vector=0x7fff5fbfe800) at eval.c:3210
#32 0x000000010011b034 in Ffuncall (nargs=4412514885,
args=0x1037d42d2) at eval.c:3035
#33 0x000000010011d506 in apply1 (fn=Cannot access memory at address 0x0
) at eval.c:2722
#34 0x0000000100116755 in Fcall_interactively
(function=140734799800848, record_flag=140734799800848,
keys=140734799800848) at callint.c:379
#35 0x000000010011af73 in Ffuncall (nargs=4353508050,
args=0x10011b108) at eval.c:2993
#36 0x000000010011def6 in call3 (fn=4, arg1=0, arg2=140734799800496,
arg3=4296006988) at eval.c:2786
#37 0x00000001000b4b15 in command_loop_1 () at keyboard.c:1571
#38 0x000000010011e723 in internal_condition_case (bfun=0x1000b44d0
<command_loop_1>, handlers=4320201482, hfun=0x1000b5a60 <cmd_error>)
at eval.c:1499
#39 0x00000001000b44ae in command_loop_2 (ignore=4320271674) at keyboard.c:1159
#40 0x000000010011e828 in internal_catch (tag=4320271674,
func=0x1000b4470 <command_loop_2>, arg=4320271674) at eval.c:1256
#41 0x00000001000b5fc0 in command_loop [inlined] () at
/usr/local/emacs/trunk/src/keyboard.c:1138
#42 0x00000001000b5fc0 in recursive_edit_1 () at keyboard.c:758
#43 0x00000001000a5ddc in Frecursive_edit () at keyboard.c:822
#44 0x00000001000a2924 in main (argc=25230234, argv=0x7fff5fbff0a0) at
emacs.c:1709
Lisp Backtrace:
"byte-code" (0x5fbfd850)
"byte-code" (0x5fbfdb10)
"vm-read-index-file" (0x5fbfde58)
"byte-code" (0x5fbfdf10)
"vm-read-index-file-maybe" (0x5fbfe258)
"byte-code" (0x5fbfe340)
"vm" (0x5fbfe650)
"vm-my-open-folder-RMAIL" (0x5fbfe8b0)
"call-interactively" (0x5fbfeaa8)
(gdb)
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-20 6:34 Memory again emacs user
@ 2011-12-20 7:43 ` Eli Zaretskii
2011-12-20 12:05 ` emacs user
0 siblings, 1 reply; 87+ messages in thread
From: Eli Zaretskii @ 2011-12-20 7:43 UTC (permalink / raw)
To: emacs user; +Cc: emacs-devel
> Date: Tue, 20 Dec 2011 08:34:44 +0200
> From: emacs user <user.emacs@gmail.com>
>
> > I'm not an expert in Apple world, but the first step looks almost obvious -
> > can you try to use 'leaks' (for example, see http://shorestreet.com/node/4)
> > and see whether it shows something useful?
> >
> > Dmitry
> >
>
> thanks! here it is. I attach both the leaks output, and the
> backtrace/ xbacktrace for a crash that happens eventually.
> At the time of this leaks report, emacs has 192Mb according to the
> activity monitor, with all buffers deleted. happy to do additional
> tests if needed.
Please set MallocStackLogging in the environment, and run this again.
Without the call-stack info, I find it hard to believe we will be able
to correlate these leaks with source code.
Thanks.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-20 7:43 ` Eli Zaretskii
@ 2011-12-20 12:05 ` emacs user
2011-12-20 13:04 ` Eli Zaretskii
0 siblings, 1 reply; 87+ messages in thread
From: emacs user @ 2011-12-20 12:05 UTC (permalink / raw)
To: emacs-devel
On Tue, Dec 20, 2011 at 9:43 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 20 Dec 2011 08:34:44 +0200
>> From: emacs user <user.emacs@gmail.com>
>>
>> > I'm not an expert in Apple world, but the first step looks almost obvious -
>> > can you try to use 'leaks' (for example, see http://shorestreet.com/node/4)
>> > and see whether it shows something useful?
>> >
>> > Dmitry
>> >
>>
>> thanks! here it is. I attach both the leaks output, and the
>> backtrace/ xbacktrace for a crash that happens eventually.
>> At the time of this leaks report, emacs has 192Mb according to the
>> activity monitor, with all buffers deleted. happy to do additional
>> tests if needed.
>
> Please set MallocStackLogging in the environment, and run this again.
> Without the call-stack info, I find it hard to believe we will be able
> to correlate these leaks with source code.
>
> Thanks.
thanks for this hint, here it is, at least the first few entries:
$ leaks Emacs
leaks(41004) malloc: recording malloc stacks to disk using standard recorder
leaks(41004) malloc: stack logs being written into
/tmp/stack-logs.41004.leaks.ZyDBey.index
Process: Emacs [40881]
Path: /usr/local/emacs/trunk/nextstep/Emacs.app/Contents/MacOS/Emacs
Load Address: 0x100000000
Identifier: org.gnu.Emacs
Version: Version 24.0.91 (9.0)
Code Type: X86-64 (Native)
Parent Process: bash [40676]
Date/Time: 2011-12-20 06:53:57.422 -0500
OS Version: Mac OS X 10.7.2 (11C74)
Report Version: 7
leaks Report Version: 2.0
Process 40881: 255309 nodes malloced for 63887 KB
Process 40881: 132 leaks for 15872 total leaked bytes.
Leak: 0x102895200 size=8192 zone: DefaultMallocZone_0x100a63000
0xffffffff 0xffffffff 0xffffffff 0x7fffffff ................
0x00000000 0xffffffff 0xffffffff 0xffffffff ................
0xffffffff 0xffffffff 0xffffffff 0xffffffff ................
0xffffffff 0xffffffff 0xffffffff 0xffffffff ................
0xffffffff 0xffffffff 0x00007fff 0x00000000 ................
0x00000000 0xffff0000 0xffffffff 0xffffffff ................
0xffffffff 0xffffffff 0xffffffff 0x00007fff ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
...
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:2986 | Fx_create_frame nsfns.m:1266 | x_default_parameter
frame.c:3929 | x_set_frame_parameters frame.c:2871 | x_set_font
frame.c:3226 | font_open_by_name font.c:3324 | font_load_for_lface
font.c:3261 | font_find_for_lface font.c:3198 | font_list_entities
font.c:2728 | ns_findfonts nsfont.m:407 |
CFCharacterSetAddCharactersInRange | __CFCSetMakeBitmap |
malloc_zone_malloc
Leak: 0x101680420 size=544 zone: DefaultMallocZone_0x100a63000
__NSCFString ObjC CoreFoundation
0x788d1ae8 0x00007fff 0x00000790 0x00000001 ...x............
0x00000100 0x00000000 0x00010000 0x00030002 ................
0x00050004 0x00070006 0x00090008 0x000b000a ................
0x000d000c 0x000f000e 0x00110010 0x00130012 ................
0x00150014 0x00170016 0x00190018 0x001b001a ................
0x001d001c 0x001f001e 0x00210020 0x00230022 ........ .!.".#.
0x00250024 0x00270026 0x00290028 0x002b002a $.%.&.'.(.).*.+.
0x002d002c 0x002f002e 0x00310030 0x00330032 ,.-.../.0.1.2.3.
...
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2348 | Fload lread.c:1256
| call4 eval.c:2804 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Fmessage editfns.c:3381 | message3 xdisp.c:9402 | message3_nolog
xdisp.c:9465 | echo_area_display xdisp.c:9959 | with_echo_area_buffer
xdisp.c:9785 | display_echo_area_1 xdisp.c:9992 | resize_mini_window
xdisp.c:10127 | move_it_to xdisp.c:8622 | move_it_in_display_line_to
xdisp.c:8083 | x_produce_glyphs xdisp.c:22116 | nsfont_encode_char
nsfont.m:1315 | -[EmacsGlyphStorage setString:font:] nsfont.m:1428 |
-[NSConcreteAttributedString initWithString:attributes:] |
-[NSConcreteAttributedString initWithString:] | CFStringCreateCopy |
__CFStringCreateImmutableFunnel3 | _CFRuntimeCreateInstance |
malloc_zone_malloc
Leak: 0x1075c4030 size=544 zone: DefaultMallocZone_0x100a63000
__NSCFString ObjC CoreFoundation
0x788d1ae8 0x00007fff 0x00000790 0x00000001 ...x............
0x00000100 0x00000000 0x00010000 0x00030002 ................
0x00050004 0x00070006 0x00090008 0x000b000a ................
0x000d000c 0x000f000e 0x00110010 0x00130012 ................
0x00150014 0x00170016 0x00190018 0x001b001a ................
0x001d001c 0x001f001e 0x00210020 0x00230022 ........ .!.".#.
0x00250024 0x00270026 0x00290028 0x002b002a $.%.&.'.(.).*.+.
0x002d002c 0x002f002e 0x00310030 0x00330032 ,.-.../.0.1.2.3.
...
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:2968 | Fvertical_motion indent.c:2102 | move_it_by_lines
xdisp.c:8953 | move_it_to xdisp.c:8622 | move_it_in_display_line_to
xdisp.c:8083 | x_produce_glyphs xdisp.c:22116 | nsfont_encode_char
nsfont.m:1315 | -[EmacsGlyphStorage setString:font:] nsfont.m:1428 |
-[NSConcreteAttributedString initWithString:attributes:] |
-[NSConcreteAttributedString initWithString:] | CFStringCreateCopy |
__CFStringCreateImmutableFunnel3 | _CFRuntimeCreateInstance |
malloc_zone_malloc
Leak: 0x100d25cf0 size=80 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x001ca331 0x00000001 ........1.......
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x0180303a 0x00000001 ........:0......
0x00000001 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:981 |
internal_lisp_condition_case eval.c:1454 | eval_sub eval.c:2379 |
apply_lambda eval.c:3097 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:966 | internal_catch eval.c:1256 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:981 |
internal_lisp_condition_case eval.c:359 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 | Fmessage
editfns.c:3381 | message3 xdisp.c:9402 | message3_nolog xdisp.c:9465 |
echo_area_display xdisp.c:10573 | redisplay_internal xdisp.c:12798 |
prepare_menu_bars xdisp.c:10934 | update_menu_bar xdisp.c:11056 |
ns_update_menubar nsmenu.m:396 | xmalloc_widget_value menu.c:588 |
xmalloc alloc.c:716 | unexec_malloc unexmacosx.c:1349 | malloc |
malloc_zone_malloc
Leak: 0x10161eec0 size=80 zone: DefaultMallocZone_0x100a63000
NSCTFontDescriptor ObjC AppKit
0x792a8c40 0x00007fff 0x00010f80 0x00000001 @.*y............
0x00000000 0x00000000 0x8b7fbdee 0x00007fff ................
0x00000000 0x00000000 0x0161eef0 0x00000001 ..........a.....
0x787d4a60 0x00007fff 0x0161ede0 0x00000001 `J}x......a.....
0x80000000 0x00000000 0x0161e820 0x00000001 ........ .a.....
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:2986 | Fx_create_frame nsfns.m:1266 | x_default_parameter
frame.c:3929 | x_set_frame_parameters frame.c:2871 | x_set_font
frame.c:3226 | font_open_by_name font.c:3324 | font_load_for_lface
font.c:3261 | font_find_for_lface font.c:3198 | font_list_entities
font.c:2728 | ns_findfonts nsfont.m:541 | +[NSObject new] |
-[NSFontDescriptor init] | -[NSFontDescriptor initWithFontAttributes:]
| -[NSFontDescriptor _initWithFontAttributes:options:] |
CTFontDescriptorCreateWithAttributesAndOptions |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x101680640 size=80 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000100 0x00000000 ................
0x00000000 0x00000000 0x00000001 0x00000001 ................
0x00000002 0x00000000 0x00000100 0x00000000 ................
0x01680690 0x00000001 0x00000000 0x00000000 ..h.............
0x00000000 0x00000000 0x00000000 0x00000000 ................
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2348 | Fload lread.c:1256
| call4 eval.c:2804 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Fmessage editfns.c:3381 | message3 xdisp.c:9402 | message3_nolog
xdisp.c:9465 | echo_area_display xdisp.c:9959 | with_echo_area_buffer
xdisp.c:9785 | display_echo_area_1 xdisp.c:9992 | resize_mini_window
xdisp.c:10127 | move_it_to xdisp.c:8622 | move_it_in_display_line_to
xdisp.c:8083 | x_produce_glyphs xdisp.c:22116 | nsfont_encode_char
nsfont.m:1315 | -[EmacsGlyphStorage setString:font:] nsfont.m:1428 |
-[NSConcreteAttributedString initWithString:attributes:] |
-[NSRLEArray init] | -[NSRLEArray initWithRefCountedRunArray:] |
-[NSRLEArray _makeNewListFrom:] | malloc_zone_calloc
Leak: 0x1016db270 size=80 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x001ca331 0x00000001 ........1.......
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x0180303a 0x00000001 ........:0......
0x00000001 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 |
Fredisplay dispnew.c:6085 | redisplay_preserve_echo_area xdisp.c:13410
| redisplay_internal xdisp.c:12798 | prepare_menu_bars xdisp.c:10934 |
update_menu_bar xdisp.c:11056 | ns_update_menubar nsmenu.m:396 |
xmalloc_widget_value menu.c:588 | xmalloc alloc.c:716 | unexec_malloc
unexmacosx.c:1349 | malloc | malloc_zone_malloc
Leak: 0x10202f660 size=80 zone: DefaultMallocZone_0x100a63000
NSCTFontDescriptor ObjC AppKit
0x792a8c40 0x00007fff 0x00010f80 0x00000001 @.*y............
0x00000000 0x00000000 0x8b7fbdee 0x00007fff ................
0x00000000 0x00000000 0x0202f690 0x00000001 ................
0x787d4a60 0x00007fff 0x0202f550 0x00000001 `J}x....P.......
0x80000000 0x00000000 0x0161e820 0x00000001 ........ .a.....
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2340 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Finternal_merge_in_global_face xfaces.c:3823 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3261 | font_find_for_lface
font.c:3198 | font_list_entities font.c:2728 | ns_findfonts
nsfont.m:541 | +[NSObject new] | -[NSFontDescriptor init] |
-[NSFontDescriptor initWithFontAttributes:] | -[NSFontDescriptor
_initWithFontAttributes:options:] |
CTFontDescriptorCreateWithAttributesAndOptions |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x105088d90 size=80 zone: DefaultMallocZone_0x100a63000
_NSImageAuxiliary ObjC AppKit
0x792a99b0 0x00007fff 0x02019e10 0x00000001 ..*y............
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x3ff00000 ...............?
0x00000000 0x3ff00000 0x00000000 0x00000000 .......?........
0x00000000 0x00000000 0x00000000 0x00000000 ................
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 | Fx_create_frame
nsfns.m:1351 | x_default_parameter frame.c:3929 |
x_set_frame_parameters frame.c:2920 | ns_implicitly_set_icon_type
nsfns.m:827 | -[NSWorkspace iconForFileType:] | -[NSImage
_initWithIconRef:includeThumbnail:] | -[NSImage initWithSize:] |
-[NSImage _allocAuxiliaryStorage] | _objc_rootAlloc | +[NSObject
allocWithZone:] | class_createInstance | calloc | malloc_zone_calloc
Leak: 0x105235600 size=80 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x001ca331 0x00000001 ........1.......
0x00000000 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x0180303a 0x00000001 ........:0......
0x00000001 0x00000000 0x00000000 0x00000000 ................
0x00000000 0x00000000 0x00000000 0x00000000 ................
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:981 |
internal_lisp_condition_case eval.c:1454 | eval_sub eval.c:2379 |
apply_lambda eval.c:3097 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:966 | internal_catch eval.c:1256 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:981 |
internal_lisp_condition_case eval.c:1454 | eval_sub eval.c:2379 |
apply_lambda eval.c:3097 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 | Fredisplay
dispnew.c:6085 | redisplay_preserve_echo_area xdisp.c:13410 |
redisplay_internal xdisp.c:12798 | prepare_menu_bars xdisp.c:10934 |
update_menu_bar xdisp.c:11056 | ns_update_menubar nsmenu.m:396 |
xmalloc_widget_value menu.c:588 | xmalloc alloc.c:716 | unexec_malloc
unexmacosx.c:1349 | malloc | malloc_zone_malloc
Leak: 0x1075b6030 size=80 zone: DefaultMallocZone_0x100a63000
0x00000000 0x00000000 0x00000100 0x00000000 ................
0x00000000 0x00000000 0x00000001 0x00000001 ................
0x00000002 0x00000000 0x00000100 0x00000000 ................
0x075c3a40 0x00000001 0x00000000 0x00000000 @:\.............
0x00000000 0x00000000 0x00000000 0x00000000 ................
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:2968 | Fvertical_motion indent.c:2102 | move_it_by_lines
xdisp.c:8953 | move_it_to xdisp.c:8622 | move_it_in_display_line_to
xdisp.c:8083 | x_produce_glyphs xdisp.c:22116 | nsfont_encode_char
nsfont.m:1315 | -[EmacsGlyphStorage setString:font:] nsfont.m:1428 |
-[NSConcreteAttributedString initWithString:attributes:] |
-[NSRLEArray init] | -[NSRLEArray initWithRefCountedRunArray:] |
-[NSRLEArray _makeNewListFrom:] | malloc_zone_calloc
Leak: 0x1010e6d70 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:2986 | Fx_create_frame nsfns.m:1266 | x_default_parameter
frame.c:3929 | x_set_frame_parameters frame.c:2871 | x_set_font
frame.c:3226 | font_open_by_name font.c:3324 | font_load_for_lface
font.c:3261 | font_find_for_lface font.c:3198 | font_list_entities
font.c:2728 | ns_findfonts nsfont.m:511 | ns_spec_to_descriptor
nsfont.m:130 | +[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10161f520 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:2986 | Fx_create_frame nsfns.m:1266 | x_default_parameter
frame.c:3929 | x_set_frame_parameters frame.c:2871 | x_set_font
frame.c:3226 | font_open_by_name font.c:3324 | font_load_for_lface
font.c:3273 | font_open_entity font.c:2839 | nsfont_open nsfont.m:675
| ns_spec_to_descriptor nsfont.m:130 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10161f560 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:2986 | Fx_create_frame nsfns.m:1266 | x_default_parameter
frame.c:3929 | x_set_frame_parameters frame.c:2871 | x_set_font
frame.c:3226 | font_open_by_name font.c:3324 | font_load_for_lface
font.c:3273 | font_open_entity font.c:2839 | nsfont_open nsfont.m:675
| ns_spec_to_descriptor nsfont.m:134 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x101623890 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2348 | Fload lread.c:1256
| call4 eval.c:2804 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Fmessage editfns.c:3381 | message3 xdisp.c:9402 | message3_nolog
xdisp.c:9465 | echo_area_display xdisp.c:9959 | with_echo_area_buffer
xdisp.c:9785 | display_echo_area_1 xdisp.c:9992 | resize_mini_window
xdisp.c:10106 | init_iterator xdisp.c:2575 | recompute_basic_faces
xfaces.c:839 | realize_basic_faces xfaces.c:5290 | realize_named_face
xfaces.c:5474 | realize_face xfaces.c:5608 | font_load_for_lface
font.c:3273 | font_open_entity font.c:2839 | nsfont_open nsfont.m:675
| ns_spec_to_descriptor nsfont.m:130 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10167ae00 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2348 | Fload lread.c:1256
| call4 eval.c:2804 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Fmessage editfns.c:3381 | message3 xdisp.c:9402 | message3_nolog
xdisp.c:9465 | echo_area_display xdisp.c:9959 | with_echo_area_buffer
xdisp.c:9785 | display_echo_area_1 xdisp.c:9992 | resize_mini_window
xdisp.c:10106 | init_iterator xdisp.c:2575 | recompute_basic_faces
xfaces.c:839 | realize_basic_faces xfaces.c:5290 | realize_named_face
xfaces.c:5474 | realize_face xfaces.c:5608 | font_load_for_lface
font.c:3273 | font_open_entity font.c:2839 | nsfont_open nsfont.m:675
| ns_spec_to_descriptor nsfont.m:134 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x101680db0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2348 | Fload lread.c:1256
| call4 eval.c:2804 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Fmessage editfns.c:3381 | message3 xdisp.c:9402 | message3_nolog
xdisp.c:9465 | echo_area_display xdisp.c:10563 | redisplay_mode_lines
| display_mode_lines xdisp.c:19798 | display_mode_line xdisp.c:19857 |
display_mode_element xdisp.c:20339 | display_mode_element
xdisp.c:20339 | display_mode_element xdisp.c:20167 | display_string
xdisp.c:21409 | face_at_string_position xfaces.c:4501 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3273 | font_open_entity
font.c:2839 | nsfont_open nsfont.m:675 | ns_spec_to_descriptor
nsfont.m:130 | +[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x101680df0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2348 | Fload lread.c:1256
| call4 eval.c:2804 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Fmessage editfns.c:3381 | message3 xdisp.c:9402 | message3_nolog
xdisp.c:9465 | echo_area_display xdisp.c:10563 | redisplay_mode_lines
| display_mode_lines xdisp.c:19798 | display_mode_line xdisp.c:19857 |
display_mode_element xdisp.c:20339 | display_mode_element
xdisp.c:20339 | display_mode_element xdisp.c:20167 | display_string
xdisp.c:21409 | face_at_string_position xfaces.c:4501 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3273 | font_open_entity
font.c:2839 | nsfont_open nsfont.m:675 | ns_spec_to_descriptor
nsfont.m:134 | +[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x102001100 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:2986 | Fx_create_frame nsfns.m:1266 | x_default_parameter
frame.c:3929 | x_set_frame_parameters frame.c:2871 | x_set_font
frame.c:3226 | font_open_by_name font.c:3324 | font_load_for_lface
font.c:3261 | font_find_for_lface font.c:3198 | font_list_entities
font.c:2728 | ns_findfonts nsfont.m:511 | ns_spec_to_descriptor
nsfont.m:134 | +[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10202f1d0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2340 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Finternal_merge_in_global_face xfaces.c:3823 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3261 | font_find_for_lface
font.c:3198 | font_list_entities font.c:2728 | ns_findfonts
nsfont.m:511 | ns_spec_to_descriptor nsfont.m:130 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10202f210 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2340 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Finternal_merge_in_global_face xfaces.c:3823 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3261 | font_find_for_lface
font.c:3198 | font_list_entities font.c:2728 | ns_findfonts
nsfont.m:511 | ns_spec_to_descriptor nsfont.m:134 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10202faf0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2340 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Finternal_merge_in_global_face xfaces.c:3823 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3273 | font_open_entity
font.c:2839 | nsfont_open nsfont.m:675 | ns_spec_to_descriptor
nsfont.m:130 | +[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10202fb30 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2340 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Finternal_merge_in_global_face xfaces.c:3823 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3273 | font_open_entity
font.c:2839 | nsfont_open nsfont.m:675 | ns_spec_to_descriptor
nsfont.m:134 | +[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x1020305c0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2340 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Fdisplay_supports_face_attributes_p xfaces.c:4501 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3273 | font_open_entity
font.c:2839 | nsfont_open nsfont.m:675 | ns_spec_to_descriptor
nsfont.m:130 | +[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x1020548a0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:807 | unbind_to
eval.c:3418 | Fprogn eval.c:359 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 | do_switch_frame
frame.c:831 | resize_mini_window xdisp.c:10106 | init_iterator
xdisp.c:2575 | recompute_basic_faces xfaces.c:839 |
realize_basic_faces xfaces.c:5290 | realize_named_face xfaces.c:5474 |
realize_face xfaces.c:5608 | font_load_for_lface font.c:3261 |
font_find_for_lface font.c:3198 | font_list_entities font.c:2728 |
ns_findfonts nsfont.m:511 | ns_spec_to_descriptor nsfont.m:130 |
+[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x1020548e0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:807 | unbind_to
eval.c:3418 | Fprogn eval.c:359 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 | do_switch_frame
frame.c:831 | resize_mini_window xdisp.c:10106 | init_iterator
xdisp.c:2575 | recompute_basic_faces xfaces.c:839 |
realize_basic_faces xfaces.c:5290 | realize_named_face xfaces.c:5474 |
realize_face xfaces.c:5608 | font_load_for_lface font.c:3261 |
font_find_for_lface font.c:3198 | font_list_entities font.c:2728 |
ns_findfonts nsfont.m:511 | ns_spec_to_descriptor nsfont.m:134 |
+[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x1020550d0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:807 | unbind_to
eval.c:3418 | Fprogn eval.c:359 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 | do_switch_frame
frame.c:831 | resize_mini_window xdisp.c:10106 | init_iterator
xdisp.c:2575 | recompute_basic_faces xfaces.c:839 |
realize_basic_faces xfaces.c:5290 | realize_named_face xfaces.c:5474 |
realize_face xfaces.c:5608 | font_load_for_lface font.c:3273 |
font_open_entity font.c:2839 | nsfont_open nsfont.m:675 |
ns_spec_to_descriptor nsfont.m:130 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x102055110 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:807 | unbind_to
eval.c:3418 | Fprogn eval.c:359 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 | do_switch_frame
frame.c:831 | resize_mini_window xdisp.c:10106 | init_iterator
xdisp.c:2575 | recompute_basic_faces xfaces.c:839 |
realize_basic_faces xfaces.c:5290 | realize_named_face xfaces.c:5474 |
realize_face xfaces.c:5608 | font_load_for_lface font.c:3273 |
font_open_entity font.c:2839 | nsfont_open nsfont.m:675 |
ns_spec_to_descriptor nsfont.m:134 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x1050381a0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 |
Fredisplay dispnew.c:6085 | redisplay_preserve_echo_area xdisp.c:13410
| redisplay_internal xdisp.c:12798 | prepare_menu_bars xdisp.c:10826 |
init_iterator xdisp.c:2575 | recompute_basic_faces xfaces.c:839 |
realize_basic_faces xfaces.c:5290 | realize_named_face xfaces.c:5474 |
realize_face xfaces.c:5608 | font_load_for_lface font.c:3273 |
font_open_entity font.c:2839 | nsfont_open nsfont.m:675 |
ns_spec_to_descriptor nsfont.m:134 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10505fe20 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 |
Fredisplay dispnew.c:6085 | redisplay_preserve_echo_area xdisp.c:13410
| redisplay_internal xdisp.c:12798 | prepare_menu_bars xdisp.c:10826 |
init_iterator xdisp.c:2575 | recompute_basic_faces xfaces.c:839 |
realize_basic_faces xfaces.c:5290 | realize_named_face xfaces.c:5474 |
realize_face xfaces.c:5608 | font_load_for_lface font.c:3261 |
font_find_for_lface font.c:3198 | font_list_entities font.c:2728 |
ns_findfonts nsfont.m:511 | ns_spec_to_descriptor nsfont.m:134 |
+[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10506bdd0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1139 | internal_catch eval.c:1256 | command_loop_2
keyboard.c:1160 | internal_condition_case eval.c:1500 | command_loop_1
keyboard.c:1448 | read_key_sequence | read_char keyboard.c:2444 |
redisplay_internal xdisp.c:13162 | redisplay_windows xdisp.c:13569 |
internal_condition_case_1 eval.c:1538 | redisplay_window_0
xdisp.c:13602 | redisplay_window xdisp.c:15479 | try_window
xdisp.c:15954 | display_line xdisp.c:18921 | get_next_display_element
xdisp.c:6388 | next_element_from_buffer xdisp.c:7659 | handle_stop
xdisp.c:3098 | handle_face_prop xdisp.c:3601 | face_at_buffer_position
xfaces.c:4501 | realize_face xfaces.c:5608 | font_load_for_lface
font.c:3273 | font_open_entity font.c:2839 | nsfont_open nsfont.m:675
| ns_spec_to_descriptor nsfont.m:130 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10506fcb0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 |
Fredisplay dispnew.c:6085 | redisplay_preserve_echo_area xdisp.c:13410
| redisplay_internal xdisp.c:12798 | prepare_menu_bars xdisp.c:10826 |
init_iterator xdisp.c:2575 | recompute_basic_faces xfaces.c:839 |
realize_basic_faces xfaces.c:5290 | realize_named_face xfaces.c:5474 |
realize_face xfaces.c:5608 | font_load_for_lface font.c:3273 |
font_open_entity font.c:2839 | nsfont_open nsfont.m:675 |
ns_spec_to_descriptor nsfont.m:130 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x105085930 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1139 | internal_catch eval.c:1256 | command_loop_2
keyboard.c:1160 | internal_condition_case eval.c:1500 | command_loop_1
keyboard.c:1448 | read_key_sequence | read_char keyboard.c:2444 |
redisplay_internal xdisp.c:13162 | redisplay_windows xdisp.c:13569 |
internal_condition_case_1 eval.c:1538 | redisplay_window_0
xdisp.c:13602 | redisplay_window xdisp.c:15479 | try_window
xdisp.c:15954 | display_line xdisp.c:18921 | get_next_display_element
xdisp.c:6388 | next_element_from_buffer xdisp.c:7659 | handle_stop
xdisp.c:3098 | handle_face_prop xdisp.c:3601 | face_at_buffer_position
xfaces.c:4501 | realize_face xfaces.c:5608 | font_load_for_lface
font.c:3273 | font_open_entity font.c:2839 | nsfont_open nsfont.m:675
| ns_spec_to_descriptor nsfont.m:130 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x105088b30 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 |
Fredisplay dispnew.c:6085 | redisplay_preserve_echo_area xdisp.c:13410
| redisplay_internal xdisp.c:12798 | prepare_menu_bars xdisp.c:10826 |
init_iterator xdisp.c:2575 | recompute_basic_faces xfaces.c:839 |
realize_basic_faces xfaces.c:5290 | realize_named_face xfaces.c:5474 |
realize_face xfaces.c:5608 | font_load_for_lface font.c:3261 |
font_find_for_lface font.c:3198 | font_list_entities font.c:2728 |
ns_findfonts nsfont.m:511 | ns_spec_to_descriptor nsfont.m:130 |
+[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x105088cf0 size=64 zone: DefaultMallocZone_0x100a63000
NSImage ObjC AppKit
0x792a9870 0x00007fff 0x00000000 0x00000000 p.*y............
0x00000000 0x40400000 0x00000000 0x40400000 ......@@......@@
0x00000189 0x00000000 0x05088de0 0x00000001 ................
0x05088d90 0x00000001 0x00000000 0x00000000 ................
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 | Fx_create_frame
nsfns.m:1351 | x_default_parameter frame.c:3929 |
x_set_frame_parameters frame.c:2920 | ns_implicitly_set_icon_type
nsfns.m:827 | -[NSWorkspace iconForFileType:] | _objc_rootAlloc |
+[NSObject allocWithZone:] | class_createInstance | calloc |
malloc_zone_calloc
Leak: 0x10508a100 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:981 |
internal_lisp_condition_case eval.c:1454 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Finternal_merge_in_global_face xfaces.c:3823 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3261 | font_find_for_lface
font.c:3198 | font_list_entities font.c:2728 | ns_findfonts
nsfont.m:511 | ns_spec_to_descriptor nsfont.m:130 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10508a140 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:981 |
internal_lisp_condition_case eval.c:1454 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Finternal_merge_in_global_face xfaces.c:3823 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3261 | font_find_for_lface
font.c:3198 | font_list_entities font.c:2728 | ns_findfonts
nsfont.m:511 | ns_spec_to_descriptor nsfont.m:134 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10508a970 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:981 |
internal_lisp_condition_case eval.c:1454 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Finternal_merge_in_global_face xfaces.c:3823 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3273 | font_open_entity
font.c:2839 | nsfont_open nsfont.m:675 | ns_spec_to_descriptor
nsfont.m:130 | +[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10508a9b0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:981 |
internal_lisp_condition_case eval.c:1454 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Finternal_merge_in_global_face xfaces.c:3823 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3273 | font_open_entity
font.c:2839 | nsfont_open nsfont.m:675 | ns_spec_to_descriptor
nsfont.m:134 | +[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10508b890 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:981 |
internal_lisp_condition_case eval.c:1454 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Fdisplay_supports_face_attributes_p xfaces.c:4501 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3273 | font_open_entity
font.c:2839 | nsfont_open nsfont.m:675 | ns_spec_to_descriptor
nsfont.m:130 | +[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10508b8d0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:981 |
internal_lisp_condition_case eval.c:1454 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Fdisplay_supports_face_attributes_p xfaces.c:4501 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3273 | font_open_entity
font.c:2839 | nsfont_open nsfont.m:675 | ns_spec_to_descriptor
nsfont.m:134 | +[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10509ad00 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:2997 | Finternal_set_lisp_face_attribute xfaces.c:3154 |
font_load_for_lface font.c:3261 | font_find_for_lface font.c:3198 |
font_list_entities font.c:2728 | ns_findfonts nsfont.m:511 |
ns_spec_to_descriptor nsfont.m:130 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10509ad40 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:2997 | Finternal_set_lisp_face_attribute xfaces.c:3154 |
font_load_for_lface font.c:3261 | font_find_for_lface font.c:3198 |
font_list_entities font.c:2728 | ns_findfonts nsfont.m:511 |
ns_spec_to_descriptor nsfont.m:134 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10509adf0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 |
Fredisplay dispnew.c:6085 | redisplay_preserve_echo_area xdisp.c:13410
| redisplay_internal xdisp.c:12798 | prepare_menu_bars xdisp.c:10826 |
init_iterator xdisp.c:2575 | recompute_basic_faces xfaces.c:839 |
realize_basic_faces xfaces.c:5290 | realize_named_face xfaces.c:5474 |
realize_face xfaces.c:5608 | font_load_for_lface font.c:3273 |
font_open_entity font.c:2839 | nsfont_open nsfont.m:675 |
ns_spec_to_descriptor nsfont.m:134 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10509b5a0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:2997 | Finternal_set_lisp_face_attribute xfaces.c:3154 |
font_load_for_lface font.c:3273 | font_open_entity font.c:2839 |
nsfont_open nsfont.m:675 | ns_spec_to_descriptor nsfont.m:130 |
+[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10509b5e0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:2997 | Finternal_set_lisp_face_attribute xfaces.c:3154 |
font_load_for_lface font.c:3273 | font_open_entity font.c:2839 |
nsfont_open nsfont.m:675 | ns_spec_to_descriptor nsfont.m:134 |
+[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10509b690 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 |
Fredisplay dispnew.c:6085 | redisplay_preserve_echo_area xdisp.c:13410
| redisplay_internal xdisp.c:12798 | prepare_menu_bars xdisp.c:10826 |
init_iterator xdisp.c:2575 | recompute_basic_faces xfaces.c:839 |
realize_basic_faces xfaces.c:5290 | realize_named_face xfaces.c:5474 |
realize_face xfaces.c:5608 | font_load_for_lface font.c:3273 |
font_open_entity font.c:2839 | nsfont_open nsfont.m:675 |
ns_spec_to_descriptor nsfont.m:130 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x10509d8b0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1139 | internal_catch eval.c:1256 | command_loop_2
keyboard.c:1160 | internal_condition_case eval.c:1500 | command_loop_1
keyboard.c:1579 | call3 eval.c:2786 | Ffuncall eval.c:2993 |
Fcall_interactively callint.c:379 | apply1 eval.c:2722 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:358 | eval_sub eval.c:2379 |
apply_lambda eval.c:3097 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:966 | internal_catch eval.c:1256 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:966 | internal_catch eval.c:1256 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:2968 | Fapply eval.c:2491 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:2968 | Fapply eval.c:2491 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3002 |
Finsert_file_contents fileio.c:3239 | call6 eval.c:2843 | Ffuncall
eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Fapply eval.c:2491 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2997 |
Faccept_process_output process.c:3993 | wait_reading_process_output
process.c:4844 | read_process_output process.c:5209 |
internal_condition_case_1 eval.c:1538 | apply1 eval.c:2729 | Fapply
eval.c:2491 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:981 |
internal_lisp_condition_case eval.c:1454 | eval_sub eval.c:2306 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:981 |
internal_lisp_condition_case eval.c:1454 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:966 | internal_catch
eval.c:1256 | eval_sub eval.c:2348 | Fread_key_sequence_vector
keyboard.c:10202 | read_key_sequence | read_char keyboard.c:2444 |
redisplay_internal xdisp.c:12798 | prepare_menu_bars xdisp.c:10826 |
init_iterator xdisp.c:2575 | recompute_basic_faces xfaces.c:839 |
realize_basic_faces xfaces.c:5290 | realize_named_face xfaces.c:5474 |
realize_face xfaces.c:5608 | font_load_for_lface font.c:3273 |
font_open_entity font.c:2839 | nsfont_open nsfont.m:675 |
ns_spec_to_descriptor nsfont.m:134 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x1050cf610 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1139 | internal_catch eval.c:1256 | command_loop_2
keyboard.c:1160 | internal_condition_case eval.c:1500 | command_loop_1
keyboard.c:1579 | call3 eval.c:2786 | Ffuncall eval.c:2993 |
Fcall_interactively callint.c:379 | apply1 eval.c:2722 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:358 | eval_sub eval.c:2379 |
apply_lambda eval.c:3097 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:966 | internal_catch eval.c:1256 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:966 | internal_catch eval.c:1256 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:2968 | Fapply eval.c:2491 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:2968 | Fapply eval.c:2491 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3002 |
Finsert_file_contents fileio.c:3239 | call6 eval.c:2843 | Ffuncall
eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Fapply eval.c:2491 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2997 |
Faccept_process_output process.c:3993 | wait_reading_process_output
process.c:4844 | read_process_output process.c:5209 |
internal_condition_case_1 eval.c:1538 | apply1 eval.c:2729 | Fapply
eval.c:2491 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:981 |
internal_lisp_condition_case eval.c:1454 | eval_sub eval.c:2306 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:981 |
internal_lisp_condition_case eval.c:1454 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:966 | internal_catch
eval.c:1256 | eval_sub eval.c:2348 | Fread_key_sequence_vector
keyboard.c:10202 | read_key_sequence | read_char keyboard.c:2444 |
redisplay_internal xdisp.c:13162 | redisplay_windows xdisp.c:13576 |
redisplay_windows xdisp.c:13569 | internal_condition_case_1
eval.c:1538 | redisplay_window_0 xdisp.c:13602 | redisplay_window
xdisp.c:15657 | move_it_vertically_backward xdisp.c:8784 | move_it_to
xdisp.c:8622 | move_it_in_display_line_to xdisp.c:8028 |
get_next_display_element xdisp.c:6388 | next_element_from_buffer
xdisp.c:7659 | handle_stop xdisp.c:3098 | handle_face_prop
xdisp.c:3601 | face_at_buffer_position xfaces.c:4501 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3273 | font_open_entity
font.c:2839 | nsfont_open nsfont.m:675 | ns_spec_to_descriptor
nsfont.m:134 | +[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x1050eaee0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 |
Fredisplay dispnew.c:6085 | redisplay_preserve_echo_area xdisp.c:13410
| redisplay_internal xdisp.c:13162 | redisplay_windows xdisp.c:13576 |
redisplay_windows xdisp.c:13569 | internal_condition_case_1
eval.c:1538 | redisplay_window_0 xdisp.c:13602 | redisplay_window
xdisp.c:15479 | try_window xdisp.c:15954 | display_line xdisp.c:18921
| get_next_display_element xdisp.c:6388 | next_element_from_buffer
xdisp.c:7659 | handle_stop xdisp.c:3098 | handle_face_prop
xdisp.c:3601 | face_at_buffer_position xfaces.c:4501 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3273 | font_open_entity
font.c:2839 | nsfont_open nsfont.m:675 | ns_spec_to_descriptor
nsfont.m:130 | +[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x1050eaf20 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 |
Fredisplay dispnew.c:6085 | redisplay_preserve_echo_area xdisp.c:13410
| redisplay_internal xdisp.c:13162 | redisplay_windows xdisp.c:13576 |
redisplay_windows xdisp.c:13569 | internal_condition_case_1
eval.c:1538 | redisplay_window_0 xdisp.c:13602 | redisplay_window
xdisp.c:15479 | try_window xdisp.c:15954 | display_line xdisp.c:18921
| get_next_display_element xdisp.c:6388 | next_element_from_buffer
xdisp.c:7659 | handle_stop xdisp.c:3098 | handle_face_prop
xdisp.c:3601 | face_at_buffer_position xfaces.c:4501 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3273 | font_open_entity
font.c:2839 | nsfont_open nsfont.m:675 | ns_spec_to_descriptor
nsfont.m:134 | +[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x1050ec470 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1139 | internal_catch eval.c:1256 | command_loop_2
keyboard.c:1160 | internal_condition_case eval.c:1500 | command_loop_1
keyboard.c:1579 | call3 eval.c:2786 | Ffuncall eval.c:2993 |
Fcall_interactively callint.c:379 | apply1 eval.c:2722 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:358 | eval_sub eval.c:2379 |
apply_lambda eval.c:3097 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:966 | internal_catch eval.c:1256 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:966 | internal_catch eval.c:1256 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:2968 | Fapply eval.c:2491 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:2968 | Fapply eval.c:2491 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3002 |
Finsert_file_contents fileio.c:3239 | call6 eval.c:2843 | Ffuncall
eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2968 |
Fapply eval.c:2491 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2997 |
Faccept_process_output process.c:3993 | wait_reading_process_output
process.c:4844 | read_process_output process.c:5209 |
internal_condition_case_1 eval.c:1538 | apply1 eval.c:2729 | Fapply
eval.c:2491 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:981 |
internal_lisp_condition_case eval.c:1454 | eval_sub eval.c:2306 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:981 |
internal_lisp_condition_case eval.c:1454 | eval_sub eval.c:2340 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:966 | internal_catch
eval.c:1256 | eval_sub eval.c:2348 | Fread_key_sequence_vector
keyboard.c:10202 | read_key_sequence | read_char keyboard.c:2444 |
redisplay_internal xdisp.c:13162 | redisplay_windows xdisp.c:13576 |
redisplay_windows xdisp.c:13569 | internal_condition_case_1
eval.c:1538 | redisplay_window_0 xdisp.c:13602 | redisplay_window
xdisp.c:15657 | move_it_vertically_backward xdisp.c:8784 | move_it_to
xdisp.c:8622 | move_it_in_display_line_to xdisp.c:8028 |
get_next_display_element xdisp.c:6388 | next_element_from_buffer
xdisp.c:7659 | handle_stop xdisp.c:3098 | handle_face_prop
xdisp.c:3601 | face_at_buffer_position xfaces.c:4501 | realize_face
xfaces.c:5608 | font_load_for_lface font.c:3273 | font_open_entity
font.c:2839 | nsfont_open nsfont.m:675 | ns_spec_to_descriptor
nsfont.m:130 | +[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x1050f8350 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1139 | internal_catch eval.c:1256 | command_loop_2
keyboard.c:1160 | internal_condition_case eval.c:1500 | command_loop_1
keyboard.c:1448 | read_key_sequence | read_char keyboard.c:2444 |
redisplay_internal xdisp.c:13162 | redisplay_windows xdisp.c:13569 |
internal_condition_case_1 eval.c:1538 | redisplay_window_0
xdisp.c:13602 | redisplay_window xdisp.c:15479 | try_window
xdisp.c:15954 | display_line xdisp.c:18921 | get_next_display_element
xdisp.c:6388 | next_element_from_buffer xdisp.c:7659 | handle_stop
xdisp.c:3098 | handle_face_prop xdisp.c:3601 | face_at_buffer_position
xfaces.c:4501 | realize_face xfaces.c:5608 | font_load_for_lface
font.c:3273 | font_open_entity font.c:2839 | nsfont_open nsfont.m:675
| ns_spec_to_descriptor nsfont.m:134 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x1052cb860 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 |
Fredisplay dispnew.c:6085 | redisplay_preserve_echo_area xdisp.c:13410
| redisplay_internal xdisp.c:13162 | redisplay_windows xdisp.c:13576 |
redisplay_windows xdisp.c:13569 | internal_condition_case_1
eval.c:1538 | redisplay_window_0 xdisp.c:13602 | redisplay_window
xdisp.c:15796 | display_mode_lines xdisp.c:19798 | display_mode_line
xdisp.c:19857 | display_mode_element xdisp.c:20339 |
display_mode_element xdisp.c:20339 | display_mode_element
xdisp.c:20167 | display_string xdisp.c:21409 | face_at_string_position
xfaces.c:4501 | realize_face xfaces.c:5608 | font_load_for_lface
font.c:3273 | font_open_entity font.c:2839 | nsfont_open nsfont.m:675
| ns_spec_to_descriptor nsfont.m:134 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x1052e1f90 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 1
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 |
Fredisplay dispnew.c:6085 | redisplay_preserve_echo_area xdisp.c:13410
| redisplay_internal xdisp.c:13162 | redisplay_windows xdisp.c:13576 |
redisplay_windows xdisp.c:13569 | internal_condition_case_1
eval.c:1538 | redisplay_window_0 xdisp.c:13602 | redisplay_window
xdisp.c:15796 | display_mode_lines xdisp.c:19798 | display_mode_line
xdisp.c:19857 | display_mode_element xdisp.c:20339 |
display_mode_element xdisp.c:20339 | display_mode_element
xdisp.c:20167 | display_string xdisp.c:21409 | face_at_string_position
xfaces.c:4501 | realize_face xfaces.c:5608 | font_load_for_lface
font.c:3273 | font_open_entity font.c:2839 | nsfont_open nsfont.m:675
| ns_spec_to_descriptor nsfont.m:130 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x1074d2960 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 | Fx_create_frame
nsfns.m:1266 | x_default_parameter frame.c:3929 |
x_set_frame_parameters frame.c:2871 | x_set_font frame.c:3226 |
font_open_by_name font.c:3324 | font_load_for_lface font.c:3273 |
font_open_entity font.c:2839 | nsfont_open nsfont.m:675 |
ns_spec_to_descriptor nsfont.m:130 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x1074f5c70 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 | Fx_create_frame
nsfns.m:1266 | x_default_parameter frame.c:3929 |
x_set_frame_parameters frame.c:2871 | x_set_font frame.c:3226 |
font_open_by_name font.c:3324 | font_load_for_lface font.c:3273 |
font_open_entity font.c:2839 | nsfont_open nsfont.m:675 |
ns_spec_to_descriptor nsfont.m:134 | +[NSObject new] |
-[__NSPlaceholderDictionary init] | -[__NSPlaceholderDictionary
initWithCapacity:] | CFDictionaryCreateMutable |
__CFDictionaryCreateGeneric | CFBasicHashCreate |
_CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x107562fc0 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 | Fx_create_frame
nsfns.m:1266 | x_default_parameter frame.c:3929 |
x_set_frame_parameters frame.c:2871 | x_set_font frame.c:3226 |
font_open_by_name font.c:3324 | font_load_for_lface font.c:3261 |
font_find_for_lface font.c:3198 | font_list_entities font.c:2728 |
ns_findfonts nsfont.m:511 | ns_spec_to_descriptor nsfont.m:130 |
+[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x1075b0f70 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 | Fx_create_frame
nsfns.m:1266 | x_default_parameter frame.c:3929 |
x_set_frame_parameters frame.c:2871 | x_set_font frame.c:3226 |
font_open_by_name font.c:3324 | font_load_for_lface font.c:3261 |
font_find_for_lface font.c:3198 | font_list_entities font.c:2728 |
ns_findfonts nsfont.m:511 | ns_spec_to_descriptor nsfont.m:134 |
+[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x1075e0540 size=64 zone: DefaultMallocZone_0x100a63000
__NSCFDictionary ObjC CoreFoundation item count: 0
Call stack: [thread 0x7fff782d9960]: | 0x1 | start | main
emacs.c:1709 | Frecursive_edit keyboard.c:822 | recursive_edit_1
keyboard.c:1138 | internal_catch eval.c:1256 | top_level_1
keyboard.c:1176 | internal_condition_case eval.c:1500 | Feval
eval.c:2188 | eval_sub eval.c:2379 | apply_lambda eval.c:3097 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | exec_byte_code
bytecode.c:981 | internal_lisp_condition_case eval.c:1454 | eval_sub
eval.c:2306 | Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 |
Ffuncall eval.c:3035 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3002 | Fload lread.c:1256 | call4 eval.c:2804 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3002 | Feval_buffer lread.c:1901 |
readevalloop lread.c:1838 | eval_sub eval.c:2379 | apply_lambda
eval.c:3097 | funcall_lambda eval.c:358 | eval_sub eval.c:2282 |
eval_sub eval.c:2282 | Fprogn eval.c:359 | eval_sub eval.c:2282 |
eval_sub eval.c:2379 | apply_lambda eval.c:3097 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 |
funcall_lambda eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall
eval.c:3035 | funcall_lambda eval.c:3217 | exec_byte_code
bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda eval.c:3217 |
exec_byte_code bytecode.c:785 | Ffuncall eval.c:3035 | funcall_lambda
eval.c:3217 | exec_byte_code bytecode.c:785 | Ffuncall eval.c:2986 |
Fredisplay dispnew.c:6085 | redisplay_preserve_echo_area xdisp.c:13410
| redisplay_internal xdisp.c:13162 | redisplay_windows xdisp.c:13569 |
internal_condition_case_1 eval.c:1538 | redisplay_window_0
xdisp.c:13602 | redisplay_window xdisp.c:15796 | display_mode_lines
xdisp.c:19798 | display_mode_line xdisp.c:19857 | display_mode_element
xdisp.c:20339 | display_mode_element xdisp.c:20339 |
display_mode_element xdisp.c:20167 | display_string xdisp.c:21409 |
face_at_string_position xfaces.c:4501 | realize_face xfaces.c:5608 |
font_load_for_lface font.c:3273 | font_open_entity font.c:2839 |
nsfont_open nsfont.m:675 | ns_spec_to_descriptor nsfont.m:130 |
+[NSObject new] | -[__NSPlaceholderDictionary init] |
-[__NSPlaceholderDictionary initWithCapacity:] |
CFDictionaryCreateMutable | __CFDictionaryCreateGeneric |
CFBasicHashCreate | _CFRuntimeCreateInstance | malloc_zone_malloc
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-20 12:05 ` emacs user
@ 2011-12-20 13:04 ` Eli Zaretskii
2011-12-20 22:07 ` Jan Djärv
2011-12-21 8:07 ` Jan Djärv
0 siblings, 2 replies; 87+ messages in thread
From: Eli Zaretskii @ 2011-12-20 13:04 UTC (permalink / raw)
To: emacs user; +Cc: emacs-devel
> Date: Tue, 20 Dec 2011 14:05:20 +0200
> From: emacs user <user.emacs@gmail.com>
>
> >> thanks! here it is. I attach both the leaks output, and the
> >> backtrace/ xbacktrace for a crash that happens eventually.
> >> At the time of this leaks report, emacs has 192Mb according to the
> >> activity monitor, with all buffers deleted. happy to do additional
> >> tests if needed.
> >
> > Please set MallocStackLogging in the environment, and run this again.
> > Without the call-stack info, I find it hard to believe we will be able
> > to correlate these leaks with source code.
> >
> > Thanks.
>
> thanks for this hint, here it is, at least the first few entries:
Thank you. Looks like all of these leaks are NS-specific, if I
understand the information correctly.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-20 13:04 ` Eli Zaretskii
@ 2011-12-20 22:07 ` Jan Djärv
2011-12-21 8:07 ` Jan Djärv
1 sibling, 0 replies; 87+ messages in thread
From: Jan Djärv @ 2011-12-20 22:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs user, emacs-devel
Hello.
20 dec 2011 kl. 14:04 skrev Eli Zaretskii:
>> Date: Tue, 20 Dec 2011 14:05:20 +0200
>> From: emacs user <user.emacs@gmail.com>
>>
>>>> thanks! here it is. I attach both the leaks output, and the
>>>> backtrace/ xbacktrace for a crash that happens eventually.
>>>> At the time of this leaks report, emacs has 192Mb according to the
>>>> activity monitor, with all buffers deleted. happy to do additional
>>>> tests if needed.
>>>
>>> Please set MallocStackLogging in the environment, and run this again.
>>> Without the call-stack info, I find it hard to believe we will be able
>>> to correlate these leaks with source code.
>>>
>>> Thanks.
>>
>> thanks for this hint, here it is, at least the first few entries:
>
> Thank you. Looks like all of these leaks are NS-specific, if I
> understand the information correctly.
They are indeed. The line numbers are a bit off again, but I get that too.
I fixed most of these and will check in when I fixed some other leaks.
Stay tuned...
Jan D.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-20 13:04 ` Eli Zaretskii
2011-12-20 22:07 ` Jan Djärv
@ 2011-12-21 8:07 ` Jan Djärv
2011-12-21 10:39 ` Carsten Mattner
2011-12-21 17:55 ` emacs user
1 sibling, 2 replies; 87+ messages in thread
From: Jan Djärv @ 2011-12-21 8:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs user, emacs-devel
Hello.
20 dec 2011 kl. 14:04 skrev Eli Zaretskii:
>> Date: Tue, 20 Dec 2011 14:05:20 +0200
>> From: emacs user <user.emacs@gmail.com>
>>
>>>> thanks! here it is. I attach both the leaks output, and the
>>>> backtrace/ xbacktrace for a crash that happens eventually.
>>>> At the time of this leaks report, emacs has 192Mb according to the
>>>> activity monitor, with all buffers deleted. happy to do additional
>>>> tests if needed.
>>>
>>> Please set MallocStackLogging in the environment, and run this again.
>>> Without the call-stack info, I find it hard to believe we will be able
>>> to correlate these leaks with source code.
>>>
>>> Thanks.
>>
>> thanks for this hint, here it is, at least the first few entries:
>
> Thank you. Looks like all of these leaks are NS-specific, if I
> understand the information correctly.
I fixed most of these, but memory leaks still remains in the NS-port. Hopefully, the most common ones are gone now.
Jan D.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-21 8:07 ` Jan Djärv
@ 2011-12-21 10:39 ` Carsten Mattner
2011-12-21 17:55 ` emacs user
1 sibling, 0 replies; 87+ messages in thread
From: Carsten Mattner @ 2011-12-21 10:39 UTC (permalink / raw)
To: Jan Djärv; +Cc: emacs-devel
On Wed, Dec 21, 2011 at 9:07 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello.
>
> 20 dec 2011 kl. 14:04 skrev Eli Zaretskii:
>
>>> Date: Tue, 20 Dec 2011 14:05:20 +0200
>>> From: emacs user <user.emacs@gmail.com>
>>>
>>>>> thanks! here it is. I attach both the leaks output, and the
>>>>> backtrace/ xbacktrace for a crash that happens eventually.
>>>>> At the time of this leaks report, emacs has 192Mb according to the
>>>>> activity monitor, with all buffers deleted. happy to do additional
>>>>> tests if needed.
>>>>
>>>> Please set MallocStackLogging in the environment, and run this again.
>>>> Without the call-stack info, I find it hard to believe we will be able
>>>> to correlate these leaks with source code.
>>>>
>>>> Thanks.
>>>
>>> thanks for this hint, here it is, at least the first few entries:
>>
>> Thank you. Looks like all of these leaks are NS-specific, if I
>> understand the information correctly.
>
> I fixed most of these, but memory leaks still remains in
> the NS-port. Hopefully, the most common ones are gone now.
Thanks Jan!
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-21 8:07 ` Jan Djärv
2011-12-21 10:39 ` Carsten Mattner
@ 2011-12-21 17:55 ` emacs user
2011-12-22 14:08 ` Jan Djärv
1 sibling, 1 reply; 87+ messages in thread
From: emacs user @ 2011-12-21 17:55 UTC (permalink / raw)
To: Jan Djärv; +Cc: emacs-devel
On Wed, Dec 21, 2011 at 10:07 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello.
>
> 20 dec 2011 kl. 14:04 skrev Eli Zaretskii:
>
>>> Date: Tue, 20 Dec 2011 14:05:20 +0200
>>> From: emacs user <user.emacs@gmail.com>
>>>
>>>>> thanks! here it is. I attach both the leaks output, and the
>>>>> backtrace/ xbacktrace for a crash that happens eventually.
>>>>> At the time of this leaks report, emacs has 192Mb according to the
>>>>> activity monitor, with all buffers deleted. happy to do additional
>>>>> tests if needed.
>>>>
>>>> Please set MallocStackLogging in the environment, and run this again.
>>>> Without the call-stack info, I find it hard to believe we will be able
>>>> to correlate these leaks with source code.
>>>>
>>>> Thanks.
>>>
>>> thanks for this hint, here it is, at least the first few entries:
>>
>> Thank you. Looks like all of these leaks are NS-specific, if I
>> understand the information correctly.
>
> I fixed most of these, but memory leaks still remains in the NS-port. Hopefully, the most common ones are gone now.
>
> Jan D.
>
Thanks... The leaks command indeed reports zero leaks now. however,
emacs still grows every time I invoke vm. here is a memory report
which I get after killing all buffers, when emacs is 214 Mb large (as
seen in the Activity Monitor). is this normal?
Garbage collection stats:
((400287 . 303593) (45615 . 144) (60632 . 80546) 2488080 600138 (708 .
477) (521 . 271) (85624 . 67826))
=> 6404592+4857488 bytes in cons cells
2189520+6912 bytes in symbols
2425280+3221840 bytes in markers
11328+7632 bytes in floats
29176+15176 bytes in intervals
2739968+2170432 bytes in string headers
2488080 bytes of string chars
2488080 bytes of vector slots
Total bytes in lisp objects: 27167562 (live 16888082, dead 10279480)
Buffer ralloc memory usage:
14 buffers
29463 bytes total (24346 in gaps)
Size Gap Name
2186 987 *srecode-map-tmp*
2186 1814 *code-converting-work*
565 1570 *Buffer Details*
170 1851 *Deletions*
30 2000 *Messages*
25 2019 *extract address components*
22 2022 *canonical address*
16 5812 *code-conversion-work*
11 2040 *Echo Area 1*
0 2022 *Minibuf-1*
0 20 *vm-nonexistent-summary*
0 20 *Minibuf-0*
0 2055 *Echo Area 0*
0 20 *subst-char-in-string*
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-12-21 17:55 ` emacs user
@ 2011-12-22 14:08 ` Jan Djärv
2011-12-22 14:58 ` emacs user
0 siblings, 1 reply; 87+ messages in thread
From: Jan Djärv @ 2011-12-22 14:08 UTC (permalink / raw)
To: emacs user; +Cc: emacs-devel
21 dec 2011 kl. 18:55 skrev emacs user:
>
> Thanks... The leaks command indeed reports zero leaks now. however,
> emacs still grows every time I invoke vm. here is a memory report
> which I get after killing all buffers, when emacs is 214 Mb large (as
> seen in the Activity Monitor). is this normal?
>
As I'm not a vm-user I can't really say. But it sounds like something is not released back to the OS.
Jan D.
> Garbage collection stats:
> ((400287 . 303593) (45615 . 144) (60632 . 80546) 2488080 600138 (708 .
> 477) (521 . 271) (85624 . 67826))
>
> => 6404592+4857488 bytes in cons cells
> 2189520+6912 bytes in symbols
> 2425280+3221840 bytes in markers
> 11328+7632 bytes in floats
> 29176+15176 bytes in intervals
> 2739968+2170432 bytes in string headers
> 2488080 bytes of string chars
> 2488080 bytes of vector slots
>
> Total bytes in lisp objects: 27167562 (live 16888082, dead 10279480)
>
> Buffer ralloc memory usage:
> 14 buffers
> 29463 bytes total (24346 in gaps)
> Size Gap Name
>
> 2186 987 *srecode-map-tmp*
> 2186 1814 *code-converting-work*
> 565 1570 *Buffer Details*
> 170 1851 *Deletions*
> 30 2000 *Messages*
> 25 2019 *extract address components*
> 22 2022 *canonical address*
> 16 5812 *code-conversion-work*
> 11 2040 *Echo Area 1*
> 0 2022 *Minibuf-1*
> 0 20 *vm-nonexistent-summary*
> 0 20 *Minibuf-0*
> 0 2055 *Echo Area 0*
> 0 20 *subst-char-in-string*
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-22 14:08 ` Jan Djärv
@ 2011-12-22 14:58 ` emacs user
2011-12-22 18:54 ` emacs user
2011-12-23 0:39 ` Stefan Monnier
0 siblings, 2 replies; 87+ messages in thread
From: emacs user @ 2011-12-22 14:58 UTC (permalink / raw)
To: Jan Djärv; +Cc: emacs-devel
On Thu, Dec 22, 2011 at 4:08 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
> 21 dec 2011 kl. 18:55 skrev emacs user:
>
>>
>> Thanks... The leaks command indeed reports zero leaks now. however,
>> emacs still grows every time I invoke vm. here is a memory report
>> which I get after killing all buffers, when emacs is 214 Mb large (as
>> seen in the Activity Monitor). is this normal?
>>
>
> As I'm not a vm-user I can't really say. But it sounds like something is not released back to the OS.
>
> Jan D.
how does one go about diagnosing this? is it possible to tell if this
an elisp problem or a c-problem?
>> Garbage collection stats:
>> ((400287 . 303593) (45615 . 144) (60632 . 80546) 2488080 600138 (708 .
>> 477) (521 . 271) (85624 . 67826))
>>
>> => 6404592+4857488 bytes in cons cells
>> 2189520+6912 bytes in symbols
>> 2425280+3221840 bytes in markers
>> 11328+7632 bytes in floats
>> 29176+15176 bytes in intervals
>> 2739968+2170432 bytes in string headers
>> 2488080 bytes of string chars
>> 2488080 bytes of vector slots
>>
>> Total bytes in lisp objects: 27167562 (live 16888082, dead 10279480)
>>
>> Buffer ralloc memory usage:
>> 14 buffers
>> 29463 bytes total (24346 in gaps)
>> Size Gap Name
>>
>> 2186 987 *srecode-map-tmp*
>> 2186 1814 *code-converting-work*
>> 565 1570 *Buffer Details*
>> 170 1851 *Deletions*
>> 30 2000 *Messages*
>> 25 2019 *extract address components*
>> 22 2022 *canonical address*
>> 16 5812 *code-conversion-work*
>> 11 2040 *Echo Area 1*
>> 0 2022 *Minibuf-1*
>> 0 20 *vm-nonexistent-summary*
>> 0 20 *Minibuf-0*
>> 0 2055 *Echo Area 0*
>> 0 20 *subst-char-in-string*
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-22 14:58 ` emacs user
@ 2011-12-22 18:54 ` emacs user
2011-12-22 19:15 ` Jan Djärv
2011-12-22 23:09 ` Carsten Mattner
2011-12-23 0:39 ` Stefan Monnier
1 sibling, 2 replies; 87+ messages in thread
From: emacs user @ 2011-12-22 18:54 UTC (permalink / raw)
To: Jan Djärv; +Cc: emacs-devel
On Thu, Dec 22, 2011 at 4:58 PM, emacs user <user.emacs@gmail.com> wrote:
> On Thu, Dec 22, 2011 at 4:08 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>
>> 21 dec 2011 kl. 18:55 skrev emacs user:
>>
>>>
>>> Thanks... The leaks command indeed reports zero leaks now. however,
>>> emacs still grows every time I invoke vm. here is a memory report
>>> which I get after killing all buffers, when emacs is 214 Mb large (as
>>> seen in the Activity Monitor). is this normal?
>>>
>>
>> As I'm not a vm-user I can't really say. But it sounds like something is not released back to the OS.
>>
>> Jan D.
>
> how does one go about diagnosing this? is it possible to tell if this
> an elisp problem or a c-problem?
Just in case this is helpful in diagnosing this:
- The problem (rapidly growing memory and eventual crash) occurs also
with emacs -nw on mac os x.
- I tested, and as far as I can tell, this does not occur under GNU/Linux
>>> Garbage collection stats:
>>> ((400287 . 303593) (45615 . 144) (60632 . 80546) 2488080 600138 (708 .
>>> 477) (521 . 271) (85624 . 67826))
>>>
>>> => 6404592+4857488 bytes in cons cells
>>> 2189520+6912 bytes in symbols
>>> 2425280+3221840 bytes in markers
>>> 11328+7632 bytes in floats
>>> 29176+15176 bytes in intervals
>>> 2739968+2170432 bytes in string headers
>>> 2488080 bytes of string chars
>>> 2488080 bytes of vector slots
>>>
>>> Total bytes in lisp objects: 27167562 (live 16888082, dead 10279480)
>>>
>>> Buffer ralloc memory usage:
>>> 14 buffers
>>> 29463 bytes total (24346 in gaps)
>>> Size Gap Name
>>>
>>> 2186 987 *srecode-map-tmp*
>>> 2186 1814 *code-converting-work*
>>> 565 1570 *Buffer Details*
>>> 170 1851 *Deletions*
>>> 30 2000 *Messages*
>>> 25 2019 *extract address components*
>>> 22 2022 *canonical address*
>>> 16 5812 *code-conversion-work*
>>> 11 2040 *Echo Area 1*
>>> 0 2022 *Minibuf-1*
>>> 0 20 *vm-nonexistent-summary*
>>> 0 20 *Minibuf-0*
>>> 0 2055 *Echo Area 0*
>>> 0 20 *subst-char-in-string*
>>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-22 18:54 ` emacs user
@ 2011-12-22 19:15 ` Jan Djärv
2011-12-23 4:41 ` YAMAMOTO Mitsuharu
2011-12-22 23:09 ` Carsten Mattner
1 sibling, 1 reply; 87+ messages in thread
From: Jan Djärv @ 2011-12-22 19:15 UTC (permalink / raw)
To: emacs user; +Cc: emacs-devel
Hello.
Is this only when you use vm? I think gnutls had some leaks, did you link with that?
Other than running valgrind on temacs, load everything in and then print out reachable memory, I don't know how to check this.
It sounds as it isn't a leak as such, but something that is still referenced, but not needed.
Jan D.
22 dec 2011 kl. 19:54 skrev emacs user:
> On Thu, Dec 22, 2011 at 4:58 PM, emacs user <user.emacs@gmail.com> wrote:
>> On Thu, Dec 22, 2011 at 4:08 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>>
>>> 21 dec 2011 kl. 18:55 skrev emacs user:
>>>
>>>>
>>>> Thanks... The leaks command indeed reports zero leaks now. however,
>>>> emacs still grows every time I invoke vm. here is a memory report
>>>> which I get after killing all buffers, when emacs is 214 Mb large (as
>>>> seen in the Activity Monitor). is this normal?
>>>>
>>>
>>> As I'm not a vm-user I can't really say. But it sounds like something is not released back to the OS.
>>>
>>> Jan D.
>>
>> how does one go about diagnosing this? is it possible to tell if this
>> an elisp problem or a c-problem?
>
> Just in case this is helpful in diagnosing this:
> - The problem (rapidly growing memory and eventual crash) occurs also
> with emacs -nw on mac os x.
> - I tested, and as far as I can tell, this does not occur under GNU/Linux
>
>
>>>> Garbage collection stats:
>>>> ((400287 . 303593) (45615 . 144) (60632 . 80546) 2488080 600138 (708 .
>>>> 477) (521 . 271) (85624 . 67826))
>>>>
>>>> => 6404592+4857488 bytes in cons cells
>>>> 2189520+6912 bytes in symbols
>>>> 2425280+3221840 bytes in markers
>>>> 11328+7632 bytes in floats
>>>> 29176+15176 bytes in intervals
>>>> 2739968+2170432 bytes in string headers
>>>> 2488080 bytes of string chars
>>>> 2488080 bytes of vector slots
>>>>
>>>> Total bytes in lisp objects: 27167562 (live 16888082, dead 10279480)
>>>>
>>>> Buffer ralloc memory usage:
>>>> 14 buffers
>>>> 29463 bytes total (24346 in gaps)
>>>> Size Gap Name
>>>>
>>>> 2186 987 *srecode-map-tmp*
>>>> 2186 1814 *code-converting-work*
>>>> 565 1570 *Buffer Details*
>>>> 170 1851 *Deletions*
>>>> 30 2000 *Messages*
>>>> 25 2019 *extract address components*
>>>> 22 2022 *canonical address*
>>>> 16 5812 *code-conversion-work*
>>>> 11 2040 *Echo Area 1*
>>>> 0 2022 *Minibuf-1*
>>>> 0 20 *vm-nonexistent-summary*
>>>> 0 20 *Minibuf-0*
>>>> 0 2055 *Echo Area 0*
>>>> 0 20 *subst-char-in-string*
>>>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-22 19:15 ` Jan Djärv
@ 2011-12-23 4:41 ` YAMAMOTO Mitsuharu
2012-01-17 10:04 ` emacs user
0 siblings, 1 reply; 87+ messages in thread
From: YAMAMOTO Mitsuharu @ 2011-12-23 4:41 UTC (permalink / raw)
To: Jan Djärv; +Cc: emacs user, emacs-devel
> Other than running valgrind on temacs, load everything in and then
> print out reachable memory, I don't know how to check this. It
> sounds as it isn't a leak as such, but something that is still
> referenced, but not needed.
The `heap' command might give some help. Perhaps one can compare
results of `heaps -addresses all <pid>' between before and after a VM
invocation as explained in the manual page, and then use
`malloc_history' to show the stack trace.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-23 4:41 ` YAMAMOTO Mitsuharu
@ 2012-01-17 10:04 ` emacs user
2012-01-17 10:58 ` YAMAMOTO Mitsuharu
0 siblings, 1 reply; 87+ messages in thread
From: emacs user @ 2012-01-17 10:04 UTC (permalink / raw)
To: YAMAMOTO Mitsuharu; +Cc: Jan Djärv, emacs-devel
On Fri, Dec 23, 2011 at 6:41 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>> Other than running valgrind on temacs, load everything in and then
>> print out reachable memory, I don't know how to check this. It
>> sounds as it isn't a leak as such, but something that is still
>> referenced, but not needed.
>
> The `heap' command might give some help. Perhaps one can compare
> results of `heaps -addresses all <pid>' between before and after a VM
> invocation as explained in the manual page, and then use
> `malloc_history' to show the stack trace.
in addition to the heap output I emailed you earlier off-line, here is
the gdb output from a crash that just occurred within a normal session
using vm and auctex. Memory is 244Mb at this point (after killing all
buffers), crash occurred when I did M-x garbage collect:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00000001000fdad6 in mem_delete_fixup [inlined] () at
/usr/local/emacs/trunk/src/alloc.c:3860
3860 if (w->right->color == MEM_BLACK && w->left->color == MEM_BLACK)
(gdb)
(gdb) where
#0 0x00000001000fdad6 in mem_delete_fixup [inlined] () at
/usr/local/emacs/trunk/src/alloc.c:3860
#1 0x00000001000fdad6 in mem_delete (z=0x10ec72d60) at alloc.c:3797
#2 0x00000001000fdc70 in lisp_align_free (block=0x10ec72d60) at alloc.c:1142
#3 0x0000000100101fc2 in gc_sweep [inlined] () at
/usr/local/emacs/trunk/src/alloc.c:5922
#4 0x0000000100101fc2 in Fgarbage_collect () at alloc.c:3797
#5 0x000000010011a287 in Ffuncall (nargs=4542901600,
args=0x10011a448) at eval.c:2983
#6 0x0000000100116c99 in Fcall_interactively
(function=140734799800160, record_flag=140734799800160,
keys=140734799800160) at callint.c:852
#7 0x000000010011a2b3 in Ffuncall (nargs=1, args=0x10011a448) at eval.c:2993
#8 0x000000010011d236 in call3 (fn=4, arg1=4309956080,
arg2=4300590816, arg3=4536667392) at eval.c:2786
#9 0x00000001000a6265 in Fexecute_extended_command
(prefixarg=140734799800432) at keyboard.c:10391
#10 0x000000010011a293 in Ffuncall (nargs=4320145466,
args=0x10011a448) at eval.c:2986
#11 0x0000000100116c99 in Fcall_interactively
(function=140734799800880, record_flag=140734799800880,
keys=140734799800880) at callint.c:852
#12 0x000000010011a2b3 in Ffuncall (nargs=2, args=0x10011a448) at eval.c:2993
#13 0x000000010011d236 in call3 (fn=4, arg1=4320213530,
arg2=4320145514, arg3=4320145466) at eval.c:2786
#14 0x00000001000b3f75 in command_loop_1 () at keyboard.c:1571
#15 0x000000010011da63 in internal_condition_case (bfun=0x1000b3930
<command_loop_1>, handlers=4320201482, hfun=0x1000b4ec0 <cmd_error>)
at eval.c:1499
#16 0x00000001000b390e in command_loop_2 (ignore=4320271674) at keyboard.c:1159
#17 0x000000010011db68 in internal_catch (tag=4320271674,
func=0x1000b38d0 <command_loop_2>, arg=4320271674) at eval.c:1256
#18 0x00000001000b5420 in command_loop [inlined] () at
/usr/local/emacs/trunk/src/keyboard.c:1138
#19 0x00000001000b5420 in recursive_edit_1 () at keyboard.c:3797
#20 0x00000001000a523c in Frecursive_edit () at keyboard.c:822
#21 0x00000001000a1d7f in main (argc=25230234, argv=0x7fff5fbff0c0) at
emacs.c:1715
Lisp Backtrace:
"garbage-collect" (0x5fbfe658)
"call-interactively" (0x5fbfe7f8)
"execute-extended-command" (0x5fbfe928)
"call-interactively" (0x5fbfeac8)
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2012-01-17 10:04 ` emacs user
@ 2012-01-17 10:58 ` YAMAMOTO Mitsuharu
2012-01-17 13:14 ` emacs user
0 siblings, 1 reply; 87+ messages in thread
From: YAMAMOTO Mitsuharu @ 2012-01-17 10:58 UTC (permalink / raw)
To: emacs user; +Cc: Jan Djärv, emacs-devel
>>>>> On Tue, 17 Jan 2012 12:04:54 +0200, emacs user <user.emacs@gmail.com> said:
> in addition to the heap output I emailed you earlier off-line, here
> is the gdb output from a crash that just occurred within a normal
> session using vm and auctex. Memory is 244Mb at this point (after
> killing all buffers), crash occurred when I did M-x garbage collect:
Is this also reproducible on other builds such as tty-only or X11?
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2012-01-17 10:58 ` YAMAMOTO Mitsuharu
@ 2012-01-17 13:14 ` emacs user
2012-01-18 1:30 ` YAMAMOTO Mitsuharu
0 siblings, 1 reply; 87+ messages in thread
From: emacs user @ 2012-01-17 13:14 UTC (permalink / raw)
To: YAMAMOTO Mitsuharu; +Cc: emacs-devel
On Tue, Jan 17, 2012 at 12:58 PM, YAMAMOTO Mitsuharu wrote:
> Is this also reproducible on other builds such as tty-only or X11?
if I run the same executable using -nw, it just wont crash. I can
bring it to a size of over 1Gb with no buffers at all; with buffers, I
could bring it to a size of 2.5Gb. at that point I can use vm and
other packages that often crash emacs, and it's stable and happy apart
from the increasing memory. upon killing buffers, the size does go
down from 2.5Gb to 1Gb, for example, but the minimum memory size used
does consistently increase with usage.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2012-01-17 13:14 ` emacs user
@ 2012-01-18 1:30 ` YAMAMOTO Mitsuharu
0 siblings, 0 replies; 87+ messages in thread
From: YAMAMOTO Mitsuharu @ 2012-01-18 1:30 UTC (permalink / raw)
To: emacs user; +Cc: emacs-devel
>>>>> On Tue, 17 Jan 2012 15:14:10 +0200, emacs user <user.emacs@gmail.com> said:
> On Tue, Jan 17, 2012 at 12:58 PM, YAMAMOTO Mitsuharu wrote:
>> Is this also reproducible on other builds such as tty-only or X11?
> if I run the same executable using -nw, it just wont crash. I can
> bring it to a size of over 1Gb with no buffers at all; with buffers,
> I could bring it to a size of 2.5Gb. at that point I can use vm and
> other packages that often crash emacs, and it's stable and happy
> apart from the increasing memory.
This would indicate increase in RSS does not necessarily mean
unstableness you originally observed with repetitive invocations of
VM. It would be worth trying the X11 build to see its behavior is
much like the NS port with graphical frame case (crash in GC?) or tty
case (stable).
> upon killing buffers, the size does go down from 2.5Gb to 1Gb, for
> example, but the minimum memory size used does consistently increase
> with usage.
Do you mean RSS continues to increase on each invocation of VM? What
do the outputs of the `heap' command look like before and after an
invocation of VM at this stage? If you find increase in malloced
memory in these outputs, then can you identify the stack traces for
some major differences using `malloc_history'?
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-22 18:54 ` emacs user
2011-12-22 19:15 ` Jan Djärv
@ 2011-12-22 23:09 ` Carsten Mattner
1 sibling, 0 replies; 87+ messages in thread
From: Carsten Mattner @ 2011-12-22 23:09 UTC (permalink / raw)
To: emacs user; +Cc: Jan Djärv, emacs-devel
On Thu, Dec 22, 2011 at 7:54 PM, emacs user <user.emacs@gmail.com> wrote:
> On Thu, Dec 22, 2011 at 4:58 PM, emacs user <user.emacs@gmail.com> wrote:
>> On Thu, Dec 22, 2011 at 4:08 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>>
>>> 21 dec 2011 kl. 18:55 skrev emacs user:
>>>
>>>>
>>>> Thanks... The leaks command indeed reports zero leaks now. however,
>>>> emacs still grows every time I invoke vm. here is a memory report
>>>> which I get after killing all buffers, when emacs is 214 Mb large (as
>>>> seen in the Activity Monitor). is this normal?
>>>>
>>>
>>> As I'm not a vm-user I can't really say. But it sounds like something is not released back to the OS.
>>>
>>> Jan D.
>>
>> how does one go about diagnosing this? is it possible to tell if this
>> an elisp problem or a c-problem?
>
> Just in case this is helpful in diagnosing this:
> - The problem (rapidly growing memory and eventual crash) occurs also
> with emacs -nw on mac os x.
> - I tested, and as far as I can tell, this does not occur under GNU/Linux
I can second that. Even without GnuTLS or gnus/vm issues.
I only have to load a couple trivial and small source code buffers, nuke all
buffers and wait for hours. No memory given back.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-22 14:58 ` emacs user
2011-12-22 18:54 ` emacs user
@ 2011-12-23 0:39 ` Stefan Monnier
2011-12-23 10:44 ` emacs user
1 sibling, 1 reply; 87+ messages in thread
From: Stefan Monnier @ 2011-12-23 0:39 UTC (permalink / raw)
To: emacs user; +Cc: Jan Djärv, emacs-devel
>>> Thanks... The leaks command indeed reports zero leaks now. however,
>>> emacs still grows every time I invoke vm. here is a memory report
>>> which I get after killing all buffers, when emacs is 214 Mb large (as
>>> seen in the Activity Monitor). is this normal?
>> As I'm not a vm-user I can't really say. But it sounds like something is
>> not released back to the OS.
> how does one go about diagnosing this? is it possible to tell if this
> an elisp problem or a c-problem?
The GC stats you posted indicate that the GC knows of about 27MB of data
(10MB of which is actually unused but can't be returned to malloc due to
fragmentation) which doesn't account for the 214MB you mention. So it
looks like that data is held by the C code.
Of course, I don't know what the 214MB represent, if it is resident set
size, then there really seems to be a leak, whereas if it's the total
virtual size, it may also be an artifact of various other things.
Stefan
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-12-23 0:39 ` Stefan Monnier
@ 2011-12-23 10:44 ` emacs user
2012-01-05 6:13 ` emacs user
0 siblings, 1 reply; 87+ messages in thread
From: emacs user @ 2011-12-23 10:44 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Jan Djärv, emacs-devel
On Fri, Dec 23, 2011 at 2:39 AM, Stefan Monnier
> The GC stats you posted indicate that the GC knows of about 27MB of data
> (10MB of which is actually unused but can't be returned to malloc due to
> fragmentation) which doesn't account for the 214MB you mention. So it
> looks like that data is held by the C code.
>
> Of course, I don't know what the 214MB represent, if it is resident set
> size, then there really seems to be a leak, whereas if it's the total
> virtual size, it may also be an artifact of various other things.
>
>
> Stefan
here is something which I am hoping is reproducible by others:
download
http://emacsforosx.com/emacs-builds/Emacs-2011-12-23-universal-10.6.8.dmg
save to desktop.
start emacs:
$ ~/Desktop/Emacs.app/Contents/MacOS/Emacs -Q&
create a file that contains the following line many times
asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf
$ wc t : 687456 10311840 52246656 t
$ ls -l t: -rw------- 1 x staff 52246656 Dec 23 05:08 t
edit it using the above emacs.
kill all buffers, do M-x garbage-collect
look at the process:
$ ps -vefl | head -1
PID STAT TIME SL RE PAGEIN VSZ RSS LIM TSIZ
%CPU %MEM COMMAND UID PPID C STIME TTY F
PRI NI WCHAN ADDR
before editing the file:
$ ps -vefl | grep 62764
62764 S 0:00.78 0 0 0 2571020 30852 - 0
0.3 0.7 /Users/xxx/Deskt 501 62068 0 5:38AM ttys001 4006
49 0 - ffffff8012762000
after editing it, killing the buffer, and doing M-x garbage-collect
$ ps -vefl | grep 62764
62764 S 0:01.85 0 0 0 2625752 83036 - 0
0.6 2.0 /Users/xxx/Deskt 501 62068 0 5:38AM ttys001 4006
48 0 - ffffff8012762000
I am running on Lion, Macbook Air. does this help?
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-23 10:44 ` emacs user
@ 2012-01-05 6:13 ` emacs user
2012-01-05 22:37 ` Jan Djärv
0 siblings, 1 reply; 87+ messages in thread
From: emacs user @ 2012-01-05 6:13 UTC (permalink / raw)
To: Jan Djärv, Stefan Monnier; +Cc: emacs-devel
On Fri, Dec 23, 2011 at 12:44 PM, emacs user <user.emacs@gmail.com> wrote:
> On Fri, Dec 23, 2011 at 2:39 AM, Stefan Monnier
>
>> The GC stats you posted indicate that the GC knows of about 27MB of data
>> (10MB of which is actually unused but can't be returned to malloc due to
>> fragmentation) which doesn't account for the 214MB you mention. So it
>> looks like that data is held by the C code.
>>
>> Of course, I don't know what the 214MB represent, if it is resident set
>> size, then there really seems to be a leak, whereas if it's the total
>> virtual size, it may also be an artifact of various other things.
>>
>>
>> Stefan
>
> here is something which I am hoping is reproducible by others:
> download
> http://emacsforosx.com/emacs-builds/Emacs-2011-12-23-universal-10.6.8.dmg
> save to desktop.
>
> start emacs:
> $ ~/Desktop/Emacs.app/Contents/MacOS/Emacs -Q&
>
> create a file that contains the following line many times
> asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf
> $ wc t : 687456 10311840 52246656 t
> $ ls -l t: -rw------- 1 x staff 52246656 Dec 23 05:08 t
>
> edit it using the above emacs.
> kill all buffers, do M-x garbage-collect
>
> look at the process:
>
> $ ps -vefl | head -1
> PID STAT TIME SL RE PAGEIN VSZ RSS LIM TSIZ
> %CPU %MEM COMMAND UID PPID C STIME TTY F
> PRI NI WCHAN ADDR
>
> before editing the file:
> $ ps -vefl | grep 62764
> 62764 S 0:00.78 0 0 0 2571020 30852 - 0
> 0.3 0.7 /Users/xxx/Deskt 501 62068 0 5:38AM ttys001 4006
> 49 0 - ffffff8012762000
>
> after editing it, killing the buffer, and doing M-x garbage-collect
> $ ps -vefl | grep 62764
> 62764 S 0:01.85 0 0 0 2625752 83036 - 0
> 0.6 2.0 /Users/xxx/Deskt 501 62068 0 5:38AM ttys001 4006
> 48 0 - ffffff8012762000
>
> I am running on Lion, Macbook Air. does this help?
just in case this is helpful, I see the same increase in RSS using
emacs 23.3 too, but not under linux. is this a problem, or is this
increase in RSS normal?
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2012-01-05 6:13 ` emacs user
@ 2012-01-05 22:37 ` Jan Djärv
2012-01-06 9:58 ` emacs user
0 siblings, 1 reply; 87+ messages in thread
From: Jan Djärv @ 2012-01-05 22:37 UTC (permalink / raw)
To: emacs user; +Cc: Stefan Monnier, emacs-devel
Hello.
I see this increase also. Memory does not seem to be given back to the system on OSX.
Maybe we should try using gmalloc on OSX. There is problem however, the unexec for OSX
uses a special malloc for temacs and the normal one for the dumped emacs. I'm not even sure gmalloc
works on OSX.
Jan D.
5 jan 2012 kl. 07:13 skrev emacs user:
> On Fri, Dec 23, 2011 at 12:44 PM, emacs user <user.emacs@gmail.com> wrote:
>> On Fri, Dec 23, 2011 at 2:39 AM, Stefan Monnier
>>
>>> The GC stats you posted indicate that the GC knows of about 27MB of data
>>> (10MB of which is actually unused but can't be returned to malloc due to
>>> fragmentation) which doesn't account for the 214MB you mention. So it
>>> looks like that data is held by the C code.
>>>
>>> Of course, I don't know what the 214MB represent, if it is resident set
>>> size, then there really seems to be a leak, whereas if it's the total
>>> virtual size, it may also be an artifact of various other things.
>>>
>>>
>>> Stefan
>>
>> here is something which I am hoping is reproducible by others:
>> download
>> http://emacsforosx.com/emacs-builds/Emacs-2011-12-23-universal-10.6.8.dmg
>> save to desktop.
>>
>> start emacs:
>> $ ~/Desktop/Emacs.app/Contents/MacOS/Emacs -Q&
>>
>> create a file that contains the following line many times
>> asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf
>> $ wc t : 687456 10311840 52246656 t
>> $ ls -l t: -rw------- 1 x staff 52246656 Dec 23 05:08 t
>>
>> edit it using the above emacs.
>> kill all buffers, do M-x garbage-collect
>>
>> look at the process:
>>
>> $ ps -vefl | head -1
>> PID STAT TIME SL RE PAGEIN VSZ RSS LIM TSIZ
>> %CPU %MEM COMMAND UID PPID C STIME TTY F
>> PRI NI WCHAN ADDR
>>
>> before editing the file:
>> $ ps -vefl | grep 62764
>> 62764 S 0:00.78 0 0 0 2571020 30852 - 0
>> 0.3 0.7 /Users/xxx/Deskt 501 62068 0 5:38AM ttys001 4006
>> 49 0 - ffffff8012762000
>>
>> after editing it, killing the buffer, and doing M-x garbage-collect
>> $ ps -vefl | grep 62764
>> 62764 S 0:01.85 0 0 0 2625752 83036 - 0
>> 0.6 2.0 /Users/xxx/Deskt 501 62068 0 5:38AM ttys001 4006
>> 48 0 - ffffff8012762000
>>
>> I am running on Lion, Macbook Air. does this help?
>
> just in case this is helpful, I see the same increase in RSS using
> emacs 23.3 too, but not under linux. is this a problem, or is this
> increase in RSS normal?
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2012-01-05 22:37 ` Jan Djärv
@ 2012-01-06 9:58 ` emacs user
2012-01-06 11:10 ` Carsten Mattner
0 siblings, 1 reply; 87+ messages in thread
From: emacs user @ 2012-01-06 9:58 UTC (permalink / raw)
To: Jan Djärv; +Cc: Stefan Monnier, emacs-devel
things seem to be a bit better with aquamacs 2.4, where some memory is returned.
On Fri, Jan 6, 2012 at 12:37 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello.
>
> I see this increase also. Memory does not seem to be given back to the system on OSX.
> Maybe we should try using gmalloc on OSX. There is problem however, the unexec for OSX
> uses a special malloc for temacs and the normal one for the dumped emacs. I'm not even sure gmalloc
> works on OSX.
>
> Jan D.
>
> 5 jan 2012 kl. 07:13 skrev emacs user:
>
>> On Fri, Dec 23, 2011 at 12:44 PM, emacs user <user.emacs@gmail.com> wrote:
>>> On Fri, Dec 23, 2011 at 2:39 AM, Stefan Monnier
>>>
>>>> The GC stats you posted indicate that the GC knows of about 27MB of data
>>>> (10MB of which is actually unused but can't be returned to malloc due to
>>>> fragmentation) which doesn't account for the 214MB you mention. So it
>>>> looks like that data is held by the C code.
>>>>
>>>> Of course, I don't know what the 214MB represent, if it is resident set
>>>> size, then there really seems to be a leak, whereas if it's the total
>>>> virtual size, it may also be an artifact of various other things.
>>>>
>>>>
>>>> Stefan
>>>
>>> here is something which I am hoping is reproducible by others:
>>> download
>>> http://emacsforosx.com/emacs-builds/Emacs-2011-12-23-universal-10.6.8.dmg
>>> save to desktop.
>>>
>>> start emacs:
>>> $ ~/Desktop/Emacs.app/Contents/MacOS/Emacs -Q&
>>>
>>> create a file that contains the following line many times
>>> asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf
>>> $ wc t : 687456 10311840 52246656 t
>>> $ ls -l t: -rw------- 1 x staff 52246656 Dec 23 05:08 t
>>>
>>> edit it using the above emacs.
>>> kill all buffers, do M-x garbage-collect
>>>
>>> look at the process:
>>>
>>> $ ps -vefl | head -1
>>> PID STAT TIME SL RE PAGEIN VSZ RSS LIM TSIZ
>>> %CPU %MEM COMMAND UID PPID C STIME TTY F
>>> PRI NI WCHAN ADDR
>>>
>>> before editing the file:
>>> $ ps -vefl | grep 62764
>>> 62764 S 0:00.78 0 0 0 2571020 30852 - 0
>>> 0.3 0.7 /Users/xxx/Deskt 501 62068 0 5:38AM ttys001 4006
>>> 49 0 - ffffff8012762000
>>>
>>> after editing it, killing the buffer, and doing M-x garbage-collect
>>> $ ps -vefl | grep 62764
>>> 62764 S 0:01.85 0 0 0 2625752 83036 - 0
>>> 0.6 2.0 /Users/xxx/Deskt 501 62068 0 5:38AM ttys001 4006
>>> 48 0 - ffffff8012762000
>>>
>>> I am running on Lion, Macbook Air. does this help?
>>
>> just in case this is helpful, I see the same increase in RSS using
>> emacs 23.3 too, but not under linux. is this a problem, or is this
>> increase in RSS normal?
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2012-01-06 9:58 ` emacs user
@ 2012-01-06 11:10 ` Carsten Mattner
0 siblings, 0 replies; 87+ messages in thread
From: Carsten Mattner @ 2012-01-06 11:10 UTC (permalink / raw)
To: Jan Djärv; +Cc: Stefan Monnier, emacs-devel
> On Fri, Jan 6, 2012 at 12:37 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello.
>
> I see this increase also. Memory does not seem to be given back to the system
> on OSX. Maybe we should try using gmalloc on OSX. There is problem however,
> the unexec for OSX uses a special malloc for temacs and the normal one for the
> dumped emacs. I'm not even sure gmalloc works on OSX.
Count me in for any testing of experimental changes.
It would be best to use a common scriptlet for collecting
the statistics to compare.
Jan, thanks again for fixing the crashes I was seeing.
So far no crashes, even with Ido enabled, encountered.
Fingers crossed. Huge thanks!
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
@ 2011-12-19 19:51 emacs user
2011-12-20 5:32 ` Dmitry Antipov
2012-01-06 14:28 ` Chong Yidong
0 siblings, 2 replies; 87+ messages in thread
From: emacs user @ 2011-12-19 19:51 UTC (permalink / raw)
To: emacs-devel
For whatever it's worth, I need to kill my emacs (GNU Emacs 24.0.92.1
x86_64-apple-darwin11.2.0, NS apple-appkit-1138.23) several times a
day when it reached over 300mb or it will crash. This memory usage is
*after* I kill all buffers and do M-x garbage collect. I submitted a
couple of bug reports, please see
http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-12/msg00404.html
am happy to do additional tests if anyone could guide me.
--------------------------------------------
From: Stefan Monnier
Subject: Re: Memory again
Date: Mon, 19 Dec 2011 06:26:26 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)
>> `garbage-collect' is supposed to give that info. At least it does give
>> info about the data that's kept under alloc.c's control because
>> of fragmentation (these are counted as "free cells").
> I would like to propose a function which explicitly says how much free memory
> the Emacs process holds.
For the part that alloc.c holds, the "memory-usage" package in ELPA
should do the trick (or can be improved to do it).
> It's especially useful when there is a way to ask system malloc about
> how much free memory is in the heap.
It'd be great to add this data when available, indeed. Patch welcome.
> This may be helpful to distinguish real heap fragmentation from memory
> leaks and other misuses - if the sum of values returned by
> 'memory-free' is, say, 10% of heap size, then the real fragmentation
> enters into the game.
It may also be important to try and keep track of other allocations,
which are not under alloc.c's control (e.g. allocations performed by
GUI libraries).
>> I agree that we're probably going to see better overall results by
>> improving general memory use than by trying to attack
>> fragmentation problems.
> Among this list's subscribers, Nix <address@hidden> is constantly
> reporting an enormous memory usage caused by Gnus.
I think we still have a leak there somewhere.
Stefan
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-12-19 19:51 emacs user
@ 2011-12-20 5:32 ` Dmitry Antipov
2012-01-06 14:28 ` Chong Yidong
1 sibling, 0 replies; 87+ messages in thread
From: Dmitry Antipov @ 2011-12-20 5:32 UTC (permalink / raw)
To: emacs-devel
On 12/19/2011 11:51 PM, emacs user wrote:
> For whatever it's worth, I need to kill my emacs (GNU Emacs 24.0.92.1
> x86_64-apple-darwin11.2.0, NS apple-appkit-1138.23) several times a
> day when it reached over 300mb or it will crash. This memory usage is
> *after* I kill all buffers and do M-x garbage collect. I submitted a
> couple of bug reports, please see
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-12/msg00404.html
> am happy to do additional tests if anyone could guide me.
I'm not an expert in Apple world, but the first step looks almost obvious -
can you try to use 'leaks' (for example, see http://shorestreet.com/node/4)
and see whether it shows something useful?
Dmitry
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-19 19:51 emacs user
2011-12-20 5:32 ` Dmitry Antipov
@ 2012-01-06 14:28 ` Chong Yidong
2012-01-06 15:53 ` emacs user
1 sibling, 1 reply; 87+ messages in thread
From: Chong Yidong @ 2012-01-06 14:28 UTC (permalink / raw)
To: emacs user; +Cc: emacs-devel
emacs user <user.emacs@gmail.com> writes:
> For whatever it's worth, I need to kill my emacs (GNU Emacs 24.0.92.1
> x86_64-apple-darwin11.2.0, NS apple-appkit-1138.23) several times a
> day when it reached over 300mb or it will crash. This memory usage is
> *after* I kill all buffers and do M-x garbage collect. I submitted a
> couple of bug reports, please see
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-12/msg00404.html
> am happy to do additional tests if anyone could guide me.
Is your Emacs compiled with GnuTLS support? If so, could you check if
it makes a difference compiling it without GnuTLS support?
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2012-01-06 14:28 ` Chong Yidong
@ 2012-01-06 15:53 ` emacs user
0 siblings, 0 replies; 87+ messages in thread
From: emacs user @ 2012-01-06 15:53 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
On Fri, Jan 6, 2012 at 4:28 PM, Chong Yidong <cyd@gnu.org> wrote:
> emacs user <user.emacs@gmail.com> writes:
>
>> For whatever it's worth, I need to kill my emacs (GNU Emacs 24.0.92.1
>> x86_64-apple-darwin11.2.0, NS apple-appkit-1138.23) several times a
>> day when it reached over 300mb or it will crash. This memory usage is
>> *after* I kill all buffers and do M-x garbage collect. I submitted a
>> couple of bug reports, please see
>> http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-12/msg00404.html
>> am happy to do additional tests if anyone could guide me.
>
> Is your Emacs compiled with GnuTLS support? If so, could you check if
> it makes a difference compiling it without GnuTLS support?
I tried:
cd /usr/local/emacs/trunk; make clean; ./autogen.sh; ./configure
--with-ns --without_gnutls; make install
and this still leads to RSS growing even if I kill all buffers, and
then to a crash. all it takes to see and reproduce this is to edit a
large file, kill it, and see that memory does not reduce back even
after M-x garbage-collect. Please see
http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00206.html
and note that aquamacs based on 23.3 does not seem to have this problem.
please let me know if there is anything else I can do.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Memory again
@ 2011-11-26 13:26 Carsten Mattner
2011-11-26 13:28 ` Carsten Mattner
2011-11-26 14:35 ` Dmitry Antipov
0 siblings, 2 replies; 87+ messages in thread
From: Carsten Mattner @ 2011-11-26 13:26 UTC (permalink / raw)
To: Emacs developers
Hi list,
after having stopped linking gnutls, I still seem to run into unfreed
memory according to Activity Monitor on OSX Lion 10.7.2.
After having used 4 erlang-mode buffers and having killed all buffers
for more than an hour and having run M-x garbage-collect there still
seems to be unreclaimable space.
It's been sitting there with 0 buffers in *scratch* at around 54megs
for a couple hours.
It's of course possible some of that has lazily been allocated and won't
be releases, but I'd be happy to confirm that it's not a leak somewhere.
How should we go about analyzing this?
Emacs.app build as follows:
CC='gcc -arch i386' ./configure --with-ns --without-gnutls
make bootstrap install
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-26 13:26 Carsten Mattner
@ 2011-11-26 13:28 ` Carsten Mattner
2011-11-26 14:35 ` Dmitry Antipov
1 sibling, 0 replies; 87+ messages in thread
From: Carsten Mattner @ 2011-11-26 13:28 UTC (permalink / raw)
To: Emacs developers
On Sat, Nov 26, 2011 at 2:26 PM, Carsten Mattner
<carstenmattner@googlemail.com> wrote:
> It's been sitting there with 0 buffers in *scratch* at around 54megs
> for a couple hours.
On fresh startup it's around 25 or 30 megs IIRC.
I'm keeping the process running if anybody wants me to
extract some debug info.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-26 13:26 Carsten Mattner
2011-11-26 13:28 ` Carsten Mattner
@ 2011-11-26 14:35 ` Dmitry Antipov
2011-11-26 14:48 ` Eli Zaretskii
2011-11-26 14:58 ` Carsten Mattner
1 sibling, 2 replies; 87+ messages in thread
From: Dmitry Antipov @ 2011-11-26 14:35 UTC (permalink / raw)
To: emacs-devel
On 11/26/2011 05:26 PM, Carsten Mattner wrote:
> After having used 4 erlang-mode buffers and having killed all buffers
> for more than an hour and having run M-x garbage-collect there still
> seems to be unreclaimable space.
This is an internal heap fragmentation, the most common disadvantage
of simple mark and sweep GC.
> It's been sitting there with 0 buffers in *scratch* at around 54megs
> for a couple hours.
Try to restore your 4 erlang-mode buffers and other stuff which has been
previously used to reach 54M. If the heap will not grow substantially
beyond 54M, this means that fragmented space was mostly re-used.
If you ends up with 2x or more heap, there is a serious memory leak
somewhere.
Dmitry
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-26 14:35 ` Dmitry Antipov
@ 2011-11-26 14:48 ` Eli Zaretskii
2011-11-26 17:37 ` Dmitry Antipov
2011-11-26 14:58 ` Carsten Mattner
1 sibling, 1 reply; 87+ messages in thread
From: Eli Zaretskii @ 2011-11-26 14:48 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: emacs-devel
> Date: Sat, 26 Nov 2011 18:35:49 +0400
> From: Dmitry Antipov <antipov@mvista.com>
>
> On 11/26/2011 05:26 PM, Carsten Mattner wrote:
>
> > After having used 4 erlang-mode buffers and having killed all buffers
> > for more than an hour and having run M-x garbage-collect there still
> > seems to be unreclaimable space.
>
> This is an internal heap fragmentation, the most common disadvantage
> of simple mark and sweep GC.
I don't think buffers are subject to this disadvantage, because they
are relocated when needed. Maybe I'm missing something, but please
elaborate to show what that is.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-26 14:48 ` Eli Zaretskii
@ 2011-11-26 17:37 ` Dmitry Antipov
2011-11-26 20:19 ` Eli Zaretskii
0 siblings, 1 reply; 87+ messages in thread
From: Dmitry Antipov @ 2011-11-26 17:37 UTC (permalink / raw)
To: emacs-devel
On 11/26/2011 06:48 PM, Eli Zaretskii wrote:
>> This is an internal heap fragmentation, the most common disadvantage
>> of simple mark and sweep GC.
>
> I don't think buffers are subject to this disadvantage, because they
> are relocated when needed. Maybe I'm missing something, but please
> elaborate to show what that is.
IIUC, buffer _text_ might be relocated if it can't be enlarged 'in place'.
If buffer text is already mmap()ed and grows even more, this doesn't affect
the heap allocated with sbrk(). Buffer itself ('struct buffer') can't be
relocated, as well as all other Lisp objects.
Dmitry
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-11-26 17:37 ` Dmitry Antipov
@ 2011-11-26 20:19 ` Eli Zaretskii
0 siblings, 0 replies; 87+ messages in thread
From: Eli Zaretskii @ 2011-11-26 20:19 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: emacs-devel
> Date: Sat, 26 Nov 2011 21:37:44 +0400
> From: Dmitry Antipov <antipov@mvista.com>
>
> On 11/26/2011 06:48 PM, Eli Zaretskii wrote:
>
> >> This is an internal heap fragmentation, the most common disadvantage
> >> of simple mark and sweep GC.
> >
> > I don't think buffers are subject to this disadvantage, because they
> > are relocated when needed. Maybe I'm missing something, but please
> > elaborate to show what that is.
>
> IIUC, buffer _text_ might be relocated if it can't be enlarged 'in place'.
> If buffer text is already mmap()ed and grows even more, this doesn't affect
> the heap allocated with sbrk(). Buffer itself ('struct buffer') can't be
> relocated, as well as all other Lisp objects.
That's true, but the buffer text is by far the largest component of
the buffer object. It is also the only one that changes its size,
sometimes considerably, during the buffer's life.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-26 14:35 ` Dmitry Antipov
2011-11-26 14:48 ` Eli Zaretskii
@ 2011-11-26 14:58 ` Carsten Mattner
2011-11-26 16:23 ` Eli Zaretskii
` (2 more replies)
1 sibling, 3 replies; 87+ messages in thread
From: Carsten Mattner @ 2011-11-26 14:58 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: emacs-devel
On Sat, Nov 26, 2011 at 3:35 PM, Dmitry Antipov <antipov@mvista.com> wrote:
> On 11/26/2011 05:26 PM, Carsten Mattner wrote:
>
>> After having used 4 erlang-mode buffers and having killed all buffers
>> for more than an hour and having run M-x garbage-collect there still
>> seems to be unreclaimable space.
>
> This is an internal heap fragmentation, the most common disadvantage
> of simple mark and sweep GC.
Allow me to be naive and ask this: what about compaction?
Would the allocator in use fragment the overall system memory
space if it frees more aggressively?
Does emacs fear the memory may be used by someone else
and hold onto what it claimed? Half-joking, half-serious asking.
>> It's been sitting there with 0 buffers in *scratch* at around 54megs
>> for a couple hours.
>
> Try to restore your 4 erlang-mode buffers and other stuff which has been
> previously used to reach 54M. If the heap will not grow substantially
> beyond 54M, this means that fragmented space was mostly re-used.
> If you ends up with 2x or more heap, there is a serious memory leak
> somewhere.
Nothing like that happened, but I had to restore some of the files as
it was from a temporary directory. Restoring the directory made emacs
realize the "file has changed on disk". Is this checked via a hash/checksum
or does emacs carry along more than that?
Details: before I opened the same buffers as good as I remembered it
was at 55megs up from 54.2megs (approx.) and it went up .4megs.
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-11-26 14:58 ` Carsten Mattner
@ 2011-11-26 16:23 ` Eli Zaretskii
2011-11-26 19:02 ` Carsten Mattner
2011-12-06 4:02 ` Óscar Fuentes
2011-11-26 17:54 ` Dmitry Antipov
2011-11-28 4:27 ` Stefan Monnier
2 siblings, 2 replies; 87+ messages in thread
From: Eli Zaretskii @ 2011-11-26 16:23 UTC (permalink / raw)
To: Carsten Mattner; +Cc: antipov, emacs-devel
> Date: Sat, 26 Nov 2011 15:58:49 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: emacs-devel@gnu.org
>
> Does emacs fear the memory may be used by someone else
> and hold onto what it claimed?
It doesn't, or at least shouldn't. When enough memory has been
reclaimed by GC, it should give it away to the system. At least on
some systems, I actually see that in action, after killing a large
buffer.
> Restoring the directory made emacs realize the "file has changed on
> disk". Is this checked via a hash/checksum or does emacs carry along
> more than that?
It remembers the last time stamp of the file/directory.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-26 16:23 ` Eli Zaretskii
@ 2011-11-26 19:02 ` Carsten Mattner
2011-11-26 20:31 ` Eli Zaretskii
2011-12-06 4:02 ` Óscar Fuentes
1 sibling, 1 reply; 87+ messages in thread
From: Carsten Mattner @ 2011-11-26 19:02 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: antipov, emacs-devel
On Sat, Nov 26, 2011 at 5:23 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 26 Nov 2011 15:58:49 +0100
>> From: Carsten Mattner <carstenmattner@googlemail.com>
>> Cc: emacs-devel@gnu.org
>>
>> Does emacs fear the memory may be used by someone else
>> and hold onto what it claimed?
>
> It doesn't, or at least shouldn't. When enough memory has been
> reclaimed by GC, it should give it away to the system. At least on
> some systems, I actually see that in action, after killing a large
> buffer.
As it's at 56.1megs at the moment after having left it open
for a couple more hours, I guess that Dmitry's heap fragmentation
explanation sounds most likely.
I'd like to not guess but help find potential issues which
can be corrected.
How can I instrument/help find leaks or errors in the memory
manager?
>> Restoring the directory made emacs realize the "file has changed on
>> disk". Is this checked via a hash/checksum or does emacs carry along
>> more than that?
>
> It remembers the last time stamp of the file/directory.
Ah, I see, thanks.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-26 19:02 ` Carsten Mattner
@ 2011-11-26 20:31 ` Eli Zaretskii
2011-11-26 21:00 ` Eli Zaretskii
2011-11-27 10:29 ` Carsten Mattner
0 siblings, 2 replies; 87+ messages in thread
From: Eli Zaretskii @ 2011-11-26 20:31 UTC (permalink / raw)
To: Carsten Mattner; +Cc: antipov, emacs-devel
> Date: Sat, 26 Nov 2011 20:02:27 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: antipov@mvista.com, emacs-devel@gnu.org
>
> On Sat, Nov 26, 2011 at 5:23 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Sat, 26 Nov 2011 15:58:49 +0100
> >> From: Carsten Mattner <carstenmattner@googlemail.com>
> >> Cc: emacs-devel@gnu.org
> >>
> >> Does emacs fear the memory may be used by someone else
> >> and hold onto what it claimed?
> >
> > It doesn't, or at least shouldn't. When enough memory has been
> > reclaimed by GC, it should give it away to the system. At least on
> > some systems, I actually see that in action, after killing a large
> > buffer.
>
> As it's at 56.1megs at the moment after having left it open
> for a couple more hours, I guess that Dmitry's heap fragmentation
> explanation sounds most likely.
If you start a fresh Emacs and visit a very large file, do you see the
footprint increase by approximately that file's size? And if you then
kill the buffer visiting the file, do you see the footprint go down
back to almost what it was after startup?
> I'd like to not guess but help find potential issues which
> can be corrected.
>
> How can I instrument/help find leaks or errors in the memory
> manager?
I'd start by showing the value returned by `garbage-collect' and
comparing it with the value after startup.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-26 20:31 ` Eli Zaretskii
@ 2011-11-26 21:00 ` Eli Zaretskii
2011-11-27 10:29 ` Carsten Mattner
1 sibling, 0 replies; 87+ messages in thread
From: Eli Zaretskii @ 2011-11-26 21:00 UTC (permalink / raw)
To: carstenmattner; +Cc: antipov, emacs-devel
> Date: Sat, 26 Nov 2011 22:31:10 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: antipov@mvista.com, emacs-devel@gnu.org
>
> If you start a fresh Emacs and visit a very large file, do you see the
> footprint increase by approximately that file's size? And if you then
> kill the buffer visiting the file, do you see the footprint go down
> back to almost what it was after startup?
I should amend that: depending on what packages are loaded when the
file is first time visited, you may need to do this visit-then-kill
routine a couple of times, before you see the result I'd expect: that
the footprint goes up by about the size of the file, then goes back
down to what it was before.
The first time you visit the file, you may see memory increase due to
loading packages such as the major and minor modes used by the file.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-26 20:31 ` Eli Zaretskii
2011-11-26 21:00 ` Eli Zaretskii
@ 2011-11-27 10:29 ` Carsten Mattner
2011-11-27 10:43 ` Andreas Schwab
2011-11-27 13:11 ` Eli Zaretskii
1 sibling, 2 replies; 87+ messages in thread
From: Carsten Mattner @ 2011-11-27 10:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: antipov, emacs-devel
On Sat, Nov 26, 2011 at 9:31 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 26 Nov 2011 20:02:27 +0100
>> From: Carsten Mattner <carstenmattner@googlemail.com>
>> Cc: antipov@mvista.com, emacs-devel@gnu.org
>>
>> On Sat, Nov 26, 2011 at 5:23 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> Date: Sat, 26 Nov 2011 15:58:49 +0100
>> >> From: Carsten Mattner <carstenmattner@googlemail.com>
>> >> Cc: emacs-devel@gnu.org
>> >>
>> >> Does emacs fear the memory may be used by someone else
>> >> and hold onto what it claimed?
>> >
>> > It doesn't, or at least shouldn't. When enough memory has been
>> > reclaimed by GC, it should give it away to the system. At least on
>> > some systems, I actually see that in action, after killing a large
>> > buffer.
>>
>> As it's at 56.1megs at the moment after having left it open
>> for a couple more hours, I guess that Dmitry's heap fragmentation
>> explanation sounds most likely.
>
> If you start a fresh Emacs and visit a very large file, do you see the
> footprint increase by approximately that file's size? And if you then
> kill the buffer visiting the file, do you see the footprint go down
> back to almost what it was after startup?
Totally unscientific data:
After fresh startup: 21MB
Loading xx .erl file: 21.5MB
Kill buffer: 21.7MB
Load 13499b .erl file again: 21.8MB
Kill buffer: 21.7MB
Load 13499b .erl file again: 22MB
Kill buffer: 21.8MB
Load 13499b .erl file again: 22.1MB
Kill buffer: 22.3MB
Load 13499b .erl file again: 22.2MB
Kill buffer: 22.4MB
Load 13499b .erl file again: 22.3MB
Kill buffer: 22.4MB
Load 13569b .erl file: 22.3MB
Kill buffer: 22.5MB
---------------
fresh startup without Ido: 21.2MB or 21.1MB
C-x C-f: 21.3MB
load 13499b .erl file: 21.3MB
kill buffer: 21.4MB
reload same .erl file: 21.5MB
kill buffer: 21.6MB
reload same .erl file: 21.7MB first then 21.6MB then 21.5MB
kill buffer: 21.7MB first then 21.6MB
reload same .erl file: 21.7MB first then 21.6MB
kill buffer: 21.7MB first then N/A as I had pressed C-x C-f and
then pressing C-g made Emacs.app crash. sorry :(, it sometimes crashes
on C-g on Mac OS X.
If we can come up with some automation to trace and save
data, I'd be glad to collect that.
>> I'd like to not guess but help find potential issues which
>> can be corrected.
>>
>> How can I instrument/help find leaks or errors in the memory
>> manager?
>
> I'd start by showing the value returned by `garbage-collect' and
> comparing it with the value after startup.
Where am I supposed to see the output of (garbage-collect)?
Use an elisp buffer and make it print the result?
Or in the Messages buffer which I usually kill on startup and
disable by setting message-log-max to nil.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-27 10:29 ` Carsten Mattner
@ 2011-11-27 10:43 ` Andreas Schwab
2011-11-27 13:53 ` Carsten Mattner
2011-11-27 13:11 ` Eli Zaretskii
1 sibling, 1 reply; 87+ messages in thread
From: Andreas Schwab @ 2011-11-27 10:43 UTC (permalink / raw)
To: Carsten Mattner; +Cc: Eli Zaretskii, antipov, emacs-devel
Carsten Mattner <carstenmattner@googlemail.com> writes:
> Where am I supposed to see the output of (garbage-collect)?
M-x ielm
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-27 10:29 ` Carsten Mattner
2011-11-27 10:43 ` Andreas Schwab
@ 2011-11-27 13:11 ` Eli Zaretskii
2011-11-27 13:53 ` Carsten Mattner
1 sibling, 1 reply; 87+ messages in thread
From: Eli Zaretskii @ 2011-11-27 13:11 UTC (permalink / raw)
To: Carsten Mattner; +Cc: antipov, emacs-devel
> Date: Sun, 27 Nov 2011 11:29:46 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: antipov@mvista.com, emacs-devel@gnu.org
>
> After fresh startup: 21MB
> Loading xx .erl file: 21.5MB
> Kill buffer: 21.7MB
> Load 13499b .erl file again: 21.8MB
> Kill buffer: 21.7MB
> Load 13499b .erl file again: 22MB
> Kill buffer: 21.8MB
> Load 13499b .erl file again: 22.1MB
> Kill buffer: 22.3MB
> Load 13499b .erl file again: 22.2MB
> Kill buffer: 22.4MB
> Load 13499b .erl file again: 22.3MB
> Kill buffer: 22.4MB
> Load 13569b .erl file: 22.3MB
> Kill buffer: 22.5MB
Looks like some leak, indeed.
> fresh startup without Ido: 21.2MB or 21.1MB
> C-x C-f: 21.3MB
> load 13499b .erl file: 21.3MB
> kill buffer: 21.4MB
> reload same .erl file: 21.5MB
> kill buffer: 21.6MB
> reload same .erl file: 21.7MB first then 21.6MB then 21.5MB
> kill buffer: 21.7MB first then 21.6MB
> reload same .erl file: 21.7MB first then 21.6MB
This looks normal: the memory is more or less constant.
> > I'd start by showing the value returned by `garbage-collect' and
> > comparing it with the value after startup.
>
> Where am I supposed to see the output of (garbage-collect)?
Either one of the following:
. Type "M-: (garbage-collect) RET", then find the results in *Messages*.
. Type in *scratch* "(garbage-collect)^J".
. Use ielm as pointed out by Andreas.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-27 13:11 ` Eli Zaretskii
@ 2011-11-27 13:53 ` Carsten Mattner
2011-11-27 16:44 ` Eli Zaretskii
0 siblings, 1 reply; 87+ messages in thread
From: Carsten Mattner @ 2011-11-27 13:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: antipov, emacs-devel
On Sun, Nov 27, 2011 at 2:11 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 27 Nov 2011 11:29:46 +0100
>> From: Carsten Mattner <carstenmattner@googlemail.com>
>> Cc: antipov@mvista.com, emacs-devel@gnu.org
>>
>> After fresh startup: 21MB
>> Loading xx .erl file: 21.5MB
>> Kill buffer: 21.7MB
>> Load 13499b .erl file again: 21.8MB
>> Kill buffer: 21.7MB
>> Load 13499b .erl file again: 22MB
>> Kill buffer: 21.8MB
>> Load 13499b .erl file again: 22.1MB
>> Kill buffer: 22.3MB
>> Load 13499b .erl file again: 22.2MB
>> Kill buffer: 22.4MB
>> Load 13499b .erl file again: 22.3MB
>> Kill buffer: 22.4MB
>> Load 13569b .erl file: 22.3MB
>> Kill buffer: 22.5MB
>
> Looks like some leak, indeed.
ido and ido-menu settings follow:
(autoload 'idomenu "idomenu" nil t)
(global-set-key (kbd "C-x o") 'idomenu)
(setq
ido-everywhere t
ido-use-filename-at-point 'guess
ido-create-new-buffer 'always
ido-file-extensions-order '(".erl" ".c" ".org" ".txt" ".conf")
ido-save-directory-list-file "~/.emacs.d/cache/ido.last"
ido-ignore-buffers ;; ignore these guys
'("\\` " "^\*Mess" "^\*Back" ".*Completion" "^\*Ido" "^\*trace"
"^\*compilation" "^\*GTAGS" "^session\.*" "^\*")
ido-work-directory-list '("~/" "~/Desktop" "~/Documents" "~src")
ido-case-fold t
ido-enable-last-directory-history t
ido-max-work-directory-list 30
ido-max-work-file-list 50
ido-enable-flex-matching t
ido-max-prospects 8
)
(setq confirm-nonexistent-file-or-buffer nil)
(add-hook 'ido-minibuffer-setup-hook
(function
(lambda ()
(make-local-variable 'resize-minibuffer-window-max-height)
(setq resize-minibuffer-window-max-height 1))))
(require 'ido)
(ido-mode 'both)
Anything inefficent, wrong or dangerous?
>> fresh startup without Ido: 21.2MB or 21.1MB
>> C-x C-f: 21.3MB
>> load 13499b .erl file: 21.3MB
>> kill buffer: 21.4MB
>> reload same .erl file: 21.5MB
>> kill buffer: 21.6MB
>> reload same .erl file: 21.7MB first then 21.6MB then 21.5MB
>> kill buffer: 21.7MB first then 21.6MB
>> reload same .erl file: 21.7MB first then 21.6MB
>
> This looks normal: the memory is more or less constant.
[...]
> . Use ielm as pointed out by Andreas.
>
;; M-x ielm right after startup
*** Welcome to IELM *** Type (describe-mode) for help.
ELISP> (garbage-collect)
((117223 . 17600)
(20499 . 0)
(60 . 235)
490836 365472
(106 . 70)
(90 . 200)
(18949 . 4550))
;; after loading and killing that .erl file with Ido enabled
;; at least 3 times in a row
ELISP> (garbage-collect)
((130126 . 12265)
(21652 . 3)
(129 . 345)
594990 375989
(107 . 99)
(102 . 411)
(22909 . 4055))
ELISP> (garbage-collect)
((131365 . 14983)
(21652 . 3)
(154 . 320)
595149 380380
(113 . 127)
(128 . 595)
(22911 . 4053))
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-11-27 13:53 ` Carsten Mattner
@ 2011-11-27 16:44 ` Eli Zaretskii
2011-11-27 17:37 ` Carsten Mattner
2011-11-27 17:59 ` Carsten Mattner
0 siblings, 2 replies; 87+ messages in thread
From: Eli Zaretskii @ 2011-11-27 16:44 UTC (permalink / raw)
To: Carsten Mattner; +Cc: antipov, emacs-devel
> Date: Sun, 27 Nov 2011 14:53:44 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: antipov@mvista.com, emacs-devel@gnu.org
>
> Anything inefficent, wrong or dangerous?
No inefficiency can explain a memory leak.
> ELISP> (garbage-collect)
> ((117223 . 17600)
> (20499 . 0)
> (60 . 235)
> 490836 365472
> (106 . 70)
> (90 . 200)
> (18949 . 4550))
>
> ;; after loading and killing that .erl file with Ido enabled
> ;; at least 3 times in a row
>
> ELISP> (garbage-collect)
> ((130126 . 12265)
> (21652 . 3)
> (129 . 345)
> 594990 375989
> (107 . 99)
> (102 . 411)
> (22909 . 4055))
>
> ELISP> (garbage-collect)
> ((131365 . 14983)
> (21652 . 3)
> (154 . 320)
> 595149 380380
> (113 . 127)
> (128 . 595)
> (22911 . 4053))
The number of conses seems to go up, but I'm not sure whether it's
normal or not, especially since the growth seems relatively small.
Maybe doing the same many more times will tell. Also, putting a
breakpoint in Fcons and Flist and looking at the cons cells we
allocate could give some hint.
Another way would be to try using some other mode, not erlang or ido,
and see if the memory grows similarly.
Of course, these are all stabs in the dark. I don't really know
what's going on there, just throwing some random thoughts. Caveat
emptor.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-27 16:44 ` Eli Zaretskii
@ 2011-11-27 17:37 ` Carsten Mattner
2011-11-27 17:59 ` Carsten Mattner
1 sibling, 0 replies; 87+ messages in thread
From: Carsten Mattner @ 2011-11-27 17:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: antipov, emacs-devel
On Sun, Nov 27, 2011 at 5:44 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 27 Nov 2011 14:53:44 +0100
>> From: Carsten Mattner <carstenmattner@googlemail.com>
>> Cc: antipov@mvista.com, emacs-devel@gnu.org
>>
>> Anything inefficent, wrong or dangerous?
>
> No inefficiency can explain a memory leak.
Of course not, I'm just asking for enhancements/cleanups
of my Ido settings. Especially as you seem to think that the
second results - which were without Ido - are more in line
of expected memory usage.
> The number of conses seems to go up, but I'm not sure whether it's
> normal or not, especially since the growth seems relatively small.
> Maybe doing the same many more times will tell. Also, putting a
> breakpoint in Fcons and Flist and looking at the cons cells we
> allocate could give some hint.
>
> Another way would be to try using some other mode, not erlang or ido,
> and see if the memory grows similarly.
Sure, I can also use basic Text mode for testing just to see.
It seems that
> Of course, these are all stabs in the dark. I don't really know
> what's going on there, just throwing some random thoughts. Caveat
> emptor.
If you can whip up some quick elisp to automate what you're interested
in collecting, which I doubt with me having to do some actions, call
garbage-collect, do some more, gc again..., I can run that.
Now let me do some non erlang-mode tests.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-27 16:44 ` Eli Zaretskii
2011-11-27 17:37 ` Carsten Mattner
@ 2011-11-27 17:59 ` Carsten Mattner
1 sibling, 0 replies; 87+ messages in thread
From: Carsten Mattner @ 2011-11-27 17:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: antipov, emacs-devel
On Sun, Nov 27, 2011 at 5:44 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Another way would be to try using some other mode, not erlang or ido,
> and see if the memory grows similarly.
all memory sizes are what Activity Monitor reports as "Real Memory Size"
file a is 62b plain-text
file b is 170k plain-text
following sizes are in MB
fresh start, only *scatch*: 21.4
after loading ielm: 22
load file a: 22.1
load file b: 22.2
kill both files: 22.2
load files a + b: 22.3
Ido-enabled C-x C-f and then pressing Tab repeatedly increases memory
consistently. I did that up to 24.0 cancel'ing doesn't free the memory
of what I assume to be a temporary buffer owned by Ido C-x C-f
*** Welcome to IELM *** Type (describe-mode) for help.
ELISP> (garbage-collect)
((117287 . 16644)
(20499 . 0)
(60 . 199)
491281 365472
(106 . 145)
(90 . 231)
(18999 . 4563))
ELISP> (garbage-collect)
((121212 . 19142)
(20873 . 0)
(115 . 186)
514683 369639
(106 . 173)
(120 . 977)
(20108 . 3643))
ELISP>
----------
same as above without Ido:
fresh start: 20.8
after M-x ielm: 21.4
load file a: 21.7
load file b: 22
kill both files: 22.0
load files a + b: 22.1
C-x C-f and then pressing Tab repeatedly increases memory consistently.
I did that up to 23.0. cancel'ing doesn't free the memory of what I
assume to be a temporary buffer owned by vanilla emacs C-x C-f this time
pressing C-g crashed emacs again. It just happens on Emacs --with-ns I
guess :).
forgot to save (garbage-collect) output in Ido-less test
If I have to make a guess, I'd say everything-is-a-buffer is the source
of the memory issues observed.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-26 16:23 ` Eli Zaretskii
2011-11-26 19:02 ` Carsten Mattner
@ 2011-12-06 4:02 ` Óscar Fuentes
2011-12-06 5:08 ` Eli Zaretskii
1 sibling, 1 reply; 87+ messages in thread
From: Óscar Fuentes @ 2011-12-06 4:02 UTC (permalink / raw)
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
[snip]
> It doesn't, or at least shouldn't. When enough memory has been
> reclaimed by GC, it should give it away to the system. At least on
> some systems, I actually see that in action, after killing a large
> buffer.
Just for the record: a *compile* buffer ended with 10M lines of
diagnostics emitted by a compiler. The emacs process jumped from 60MB to
526MB of RES memory. That was yesterday, and emacs keeps retaining that
memory.
I guess that as the buffer grew it was reallocated again and
again. Obviously fragmentation is at play here.
[snip]
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-06 4:02 ` Óscar Fuentes
@ 2011-12-06 5:08 ` Eli Zaretskii
2011-12-06 9:35 ` Carsten Mattner
2011-12-06 16:28 ` Óscar Fuentes
0 siblings, 2 replies; 87+ messages in thread
From: Eli Zaretskii @ 2011-12-06 5:08 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: emacs-devel
> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 06 Dec 2011 05:02:09 +0100
>
> > It doesn't, or at least shouldn't. When enough memory has been
> > reclaimed by GC, it should give it away to the system. At least on
> > some systems, I actually see that in action, after killing a large
> > buffer.
>
> Just for the record: a *compile* buffer ended with 10M lines of
> diagnostics emitted by a compiler. The emacs process jumped from 60MB to
> 526MB of RES memory.
On what OS? And was the size of the buffer comparable with 520MB?
> That was yesterday, and emacs keeps retaining that memory.
Are you saying that you killed the *compilation* buffer and Emacs
memory footprint didn't change at all? I find that hard to believe.
> I guess that as the buffer grew it was reallocated again and
> again. Obviously fragmentation is at play here.
If ralloc.c is used on the system where you did that, fragmentation
should be prevented, especially in buffer text reallocations. If
ralloc.c is not used, I believe Emacs relies on the system's memory
allocation to avoid fragmentation (that's why ralloc.c is not needed
on those systems).
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-06 5:08 ` Eli Zaretskii
@ 2011-12-06 9:35 ` Carsten Mattner
2011-12-06 10:24 ` Dmitry Antipov
2011-12-06 13:12 ` Eli Zaretskii
2011-12-06 16:28 ` Óscar Fuentes
1 sibling, 2 replies; 87+ messages in thread
From: Carsten Mattner @ 2011-12-06 9:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel
On Tue, Dec 6, 2011 at 6:08 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Óscar Fuentes <ofv@wanadoo.es>
>> That was yesterday, and emacs keeps retaining that memory.
>
> Are you saying that you killed the *compilation* buffer and Emacs
> memory footprint didn't change at all? I find that hard to believe.
I still believe this is what's happening for me on Linux 3.x and Darwin 10.7.x
when I kill a buffer and the claimed memory is not given back to the kernel.
The way I use Emacs now is to load and terminate it more often than I'd like to.
I don't tend to keep it open for a whole work day and definitely not use
--daemon.
Any ready-made instrumentation to reveal what's going on for find the root cause
or explanation of what's going?
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-06 9:35 ` Carsten Mattner
@ 2011-12-06 10:24 ` Dmitry Antipov
2011-12-06 13:07 ` Eli Zaretskii
2011-12-06 13:29 ` Stefan Monnier
2011-12-06 13:12 ` Eli Zaretskii
1 sibling, 2 replies; 87+ messages in thread
From: Dmitry Antipov @ 2011-12-06 10:24 UTC (permalink / raw)
To: emacs-devel
On 12/06/2011 01:35 PM, Carsten Mattner wrote:
> I still believe this is what's happening for me on Linux 3.x and Darwin 10.7.x
> when I kill a buffer and the claimed memory is not given back to the kernel.
Yes, it's very easy to reproduce. Generate the following C code:
#warning oops0
#warning oops1
/* a lot of */
#warning oops999999
main () {}
then M-x compile it, wait a lot until it's done, then kill *compilation*
buffer and see RSS.
I tried with 1M of #warnings, and (buffer-size *compilation*) was 58M - but
RSS grows to 2250M. During compilation, strace shows an excessive usage both
of mremap() (for buffer text, I suppose) and brk(). When I kill *compilation*,
munmap() was issued to free buffer text. Next, I call garbage-collect:
((63789 . 19159) (15579 . 0) (45 . 234) 160925 331403 (74 . 320) (696 . 251) (6794 . 10907))
But even after GC, RSS is 2192M. Oops.
Dmitry
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-12-06 10:24 ` Dmitry Antipov
@ 2011-12-06 13:07 ` Eli Zaretskii
2011-12-06 13:29 ` Stefan Monnier
1 sibling, 0 replies; 87+ messages in thread
From: Eli Zaretskii @ 2011-12-06 13:07 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: emacs-devel
> Date: Tue, 06 Dec 2011 14:24:11 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
>
> On 12/06/2011 01:35 PM, Carsten Mattner wrote:
>
> > I still believe this is what's happening for me on Linux 3.x and Darwin 10.7.x
> > when I kill a buffer and the claimed memory is not given back to the kernel.
>
> Yes, it's very easy to reproduce. Generate the following C code:
>
> #warning oops0
> #warning oops1
> /* a lot of */
> #warning oops999999
> main () {}
>
> then M-x compile it, wait a lot until it's done, then kill *compilation*
> buffer and see RSS.
I don't think this extreme case is very interesting. For that matter,
I don't think Carsten's use case is even remotely similar.
> I tried with 1M of #warnings, and (buffer-size *compilation*) was 58M - but
> RSS grows to 2250M. During compilation, strace shows an excessive usage both
> of mremap() (for buffer text, I suppose) and brk(). When I kill *compilation*,
> munmap() was issued to free buffer text. Next, I call garbage-collect:
>
> ((63789 . 19159) (15579 . 0) (45 . 234) 160925 331403 (74 . 320) (696 . 251) (6794 . 10907))
>
> But even after GC, RSS is 2192M. Oops.
If you then re-run the same compilation again, you should see the RSS
grow by very little, not by another 2GB. If so, then at least Emacs
reuses the memory as efficiently as it can.
But again, this use case is IMO not interesting in practice.
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-12-06 10:24 ` Dmitry Antipov
2011-12-06 13:07 ` Eli Zaretskii
@ 2011-12-06 13:29 ` Stefan Monnier
2011-12-06 17:20 ` Eli Zaretskii
1 sibling, 1 reply; 87+ messages in thread
From: Stefan Monnier @ 2011-12-06 13:29 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: emacs-devel
>> I still believe this is what's happening for me on Linux 3.x and
>> Darwin 10.7.x when I kill a buffer and the claimed memory is not
>> given back to the kernel.
> I tried with 1M of #warnings, and (buffer-size *compilation*) was 58M - but
> RSS grows to 2250M. During compilation, strace shows an excessive usage both
[...]
> But even after GC, RSS is 2192M. Oops.
While RSS is a useful measure for performance debugging, here it gives
us "vague" numbers only since returning 100MB to the kernel may have no
effect on the RSS if that memory was not in RAM.
Still, the point in any case is that if the buffer is 60MB, then killing
it will return those 60MB to the kernel, but it won't return to the
kernel the memory allocated for Lisp objects such as interval nodes
(used for text-properties), cons cells, strings, etc...
So of your 2250MB, only the 60MB of the buffer text will be recovered by
the kernel (well, potentially more, depending on how fragmented the Lisp
objects are, but in practice these things seems to stick around).
The rest will stay property of Emacs. This doesn't mean it's wasted:
Emacs should be perfectly able to reuse it next time it needs memory for
cons cells, strings, interval nodes, ...
E.g. re-running the same compilation should not significantly grow the
Emacs process (other than the extra 60MB, of course).
Stefan
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-12-06 13:29 ` Stefan Monnier
@ 2011-12-06 17:20 ` Eli Zaretskii
2011-12-06 20:25 ` Stefan Monnier
0 siblings, 1 reply; 87+ messages in thread
From: Eli Zaretskii @ 2011-12-06 17:20 UTC (permalink / raw)
To: Stefan Monnier; +Cc: dmantipov, emacs-devel
> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Tue, 06 Dec 2011 08:29:06 -0500
> Cc: emacs-devel@gnu.org
>
> Still, the point in any case is that if the buffer is 60MB, then killing
> it will return those 60MB to the kernel, but it won't return to the
> kernel the memory allocated for Lisp objects such as interval nodes
> (used for text-properties), cons cells, strings, etc...
??? Don't we free interval nodes that point into a buffer that is
killed? Why would we need to keep them around?
Anyway, the theory behind this experiment is that inserting lots of
text in small chunks causes massive reallocations, one each for every
time you fill the gap, and this fragmentation of the memory, which
then makes it impossible to release more than the last 60MB.
> Emacs should be perfectly able to reuse it next time it needs memory for
> cons cells, strings, interval nodes, ...
Actually, it seems to reuse even the fragmented chunks left from
previous buffer reallocations.
> E.g. re-running the same compilation should not significantly grow the
> Emacs process (other than the extra 60MB, of course).
That's what I saw, indeed.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-06 17:20 ` Eli Zaretskii
@ 2011-12-06 20:25 ` Stefan Monnier
2011-12-07 7:52 ` Eli Zaretskii
0 siblings, 1 reply; 87+ messages in thread
From: Stefan Monnier @ 2011-12-06 20:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dmantipov, emacs-devel
>> Still, the point in any case is that if the buffer is 60MB, then killing
>> it will return those 60MB to the kernel, but it won't return to the
>> kernel the memory allocated for Lisp objects such as interval nodes
>> (used for text-properties), cons cells, strings, etc...
> ??? Don't we free interval nodes that point into a buffer that is
> killed? Why would we need to keep them around?
They should be put on the free list, but whether or not they're returned
to the malloc library depends on whether or not block of those elements
is fully free. I.e. like with most other Lisp data types.
I think we could fairly easily change the code so that interval objects
are not managed by the GC but my malloc instead.
> Anyway, the theory behind this experiment is that inserting lots of
> text in small chunks causes massive reallocations, one each for every
> time you fill the gap, and this fragmentation of the memory, which
> then makes it impossible to release more than the last 60MB.
I doubt that's what happens. I think instead that the extra memory is
what is used by the various text properties we add. It is true that
Emacs makes request from malloc in "10KB" chunks for Lisp data, so any
malloc fragment smaller than that can only be used for things like
vectors I guess, but it doesn't seem sufficient to explain the effect
we're seeing.
Stefan
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-12-06 20:25 ` Stefan Monnier
@ 2011-12-07 7:52 ` Eli Zaretskii
2011-12-07 8:15 ` Dmitry Antipov
0 siblings, 1 reply; 87+ messages in thread
From: Eli Zaretskii @ 2011-12-07 7:52 UTC (permalink / raw)
To: Stefan Monnier; +Cc: dmantipov, emacs-devel
> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: dmantipov@yandex.ru, emacs-devel@gnu.org
> Date: Tue, 06 Dec 2011 15:25:59 -0500
>
> > Anyway, the theory behind this experiment is that inserting lots of
> > text in small chunks causes massive reallocations, one each for every
> > time you fill the gap, and this fragmentation of the memory, which
> > then makes it impossible to release more than the last 60MB.
>
> I doubt that's what happens. I think instead that the extra memory is
> what is used by the various text properties we add.
You are, in fact, saying that fontifying a 60-MByte compilation buffer
creates text properties and other supporting data structures that can
accrue to a total of 2G bytes. I find this extremely hard to believe.
A simple calculation will show that a file that has 1 million lines
with 5 different faces (warning, line number, column number,
underline, default) per line needs only a few million intervals -- how
can this require 2G bytes of memory?
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-07 7:52 ` Eli Zaretskii
@ 2011-12-07 8:15 ` Dmitry Antipov
2011-12-07 13:06 ` Eli Zaretskii
0 siblings, 1 reply; 87+ messages in thread
From: Dmitry Antipov @ 2011-12-07 8:15 UTC (permalink / raw)
To: emacs-devel
On 12/07/2011 11:52 AM, Eli Zaretskii wrote:
> You are, in fact, saying that fontifying a 60-MByte compilation buffer
> creates text properties and other supporting data structures that can
> accrue to a total of 2G bytes. I find this extremely hard to believe.
> A simple calculation will show that a file that has 1 million lines
> with 5 different faces (warning, line number, column number,
> underline, default) per line needs only a few million intervals -- how
> can this require 2G bytes of memory?
Start fresh Emacs instance, make sure you're in *scratch*. Type M-x
compilation-minor-mode, then eval (staying in *scratch*, of course):
(let ((x 0)) (while (< x 1000000) (insert "test:1:oops\n") (setq x (1+ x))))
Wait for completion, then see RSS. Next, kill *scratch*, M-x garbage-collect
and see RSS again.
Dmitry
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-07 8:15 ` Dmitry Antipov
@ 2011-12-07 13:06 ` Eli Zaretskii
2011-12-07 14:01 ` Stefan Monnier
0 siblings, 1 reply; 87+ messages in thread
From: Eli Zaretskii @ 2011-12-07 13:06 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: emacs-devel
> Date: Wed, 07 Dec 2011 12:15:35 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
>
> On 12/07/2011 11:52 AM, Eli Zaretskii wrote:
>
> > You are, in fact, saying that fontifying a 60-MByte compilation buffer
> > creates text properties and other supporting data structures that can
> > accrue to a total of 2G bytes. I find this extremely hard to believe.
> > A simple calculation will show that a file that has 1 million lines
> > with 5 different faces (warning, line number, column number,
> > underline, default) per line needs only a few million intervals -- how
> > can this require 2G bytes of memory?
>
> Start fresh Emacs instance, make sure you're in *scratch*. Type M-x
> compilation-minor-mode, then eval (staying in *scratch*, of course):
>
> (let ((x 0)) (while (< x 1000000) (insert "test:1:oops\n") (setq x (1+ x))))
>
> Wait for completion, then see RSS. Next, kill *scratch*, M-x garbage-collect
> and see RSS again.
How is this different from compiling a C file with 1000000 #warning
directives? What am I missing?
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-07 13:06 ` Eli Zaretskii
@ 2011-12-07 14:01 ` Stefan Monnier
2011-12-08 17:30 ` Carsten Mattner
0 siblings, 1 reply; 87+ messages in thread
From: Stefan Monnier @ 2011-12-07 14:01 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Dmitry Antipov, emacs-devel
>> > You are, in fact, saying that fontifying a 60-MByte compilation buffer
>> > creates text properties and other supporting data structures that can
>> > accrue to a total of 2G bytes. I find this extremely hard to believe.
>> > A simple calculation will show that a file that has 1 million lines
>> > with 5 different faces (warning, line number, column number,
>> > underline, default) per line needs only a few million intervals -- how
>> > can this require 2G bytes of memory?
Because the property values are themselves non-trivial.
>> Start fresh Emacs instance, make sure you're in *scratch*. Type M-x
>> compilation-minor-mode, then eval (staying in *scratch*, of course):
>>
>> (let ((x 0)) (while (< x 1000000) (insert "test:1:oops\n") (setq x (1+ x))))
>>
>> Wait for completion, then see RSS. Next, kill *scratch*, M-x garbage-collect
>> and see RSS again.
> How is this different from compiling a C file with 1000000 #warning
> directives? What am I missing?
To test your buffer-reallocation theory, you could instead do
(insert (apply #'concat (make-list 1000000 "test:1:oops\n")))
Stefan
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-12-07 14:01 ` Stefan Monnier
@ 2011-12-08 17:30 ` Carsten Mattner
2011-12-09 3:39 ` Dmitry Antipov
0 siblings, 1 reply; 87+ messages in thread
From: Carsten Mattner @ 2011-12-08 17:30 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eli Zaretskii, Dmitry Antipov, emacs-devel
On Wed, Dec 7, 2011 at 3:01 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> > You are, in fact, saying that fontifying a 60-MByte compilation buffer
>>> > creates text properties and other supporting data structures that can
>>> > accrue to a total of 2G bytes. I find this extremely hard to believe.
>>> > A simple calculation will show that a file that has 1 million lines
>>> > with 5 different faces (warning, line number, column number,
>>> > underline, default) per line needs only a few million intervals -- how
>>> > can this require 2G bytes of memory?
>
> Because the property values are themselves non-trivial.
>
>>> Start fresh Emacs instance, make sure you're in *scratch*. Type M-x
>>> compilation-minor-mode, then eval (staying in *scratch*, of course):
>>>
>>> (let ((x 0)) (while (< x 1000000) (insert "test:1:oops\n") (setq x (1+ x))))
>>>
>>> Wait for completion, then see RSS. Next, kill *scratch*, M-x garbage-collect
>>> and see RSS again.
>
>> How is this different from compiling a C file with 1000000 #warning
>> directives? What am I missing?
>
> To test your buffer-reallocation theory, you could instead do
>
> (insert (apply #'concat (make-list 1000000 "test:1:oops\n")))
Again, totally unscientific test without real instruments.
On a fresh trunk --with-ns build:
paste "(insert (apply #'concat (make-list 1000000 "test:1:oops\n")))"
to *scratch* and M-x eval-buffer: from 21.8MB to 55.8MB
as this was *scratch*, open ~/.bashrc in another buffer and kill both
and it's down to 44.4MB
M-x garbage-collect 32.9MB
M-x garbage-collect, M-x garbage-collect: 29.2MB
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-08 17:30 ` Carsten Mattner
@ 2011-12-09 3:39 ` Dmitry Antipov
2011-12-09 13:52 ` Carsten Mattner
0 siblings, 1 reply; 87+ messages in thread
From: Dmitry Antipov @ 2011-12-09 3:39 UTC (permalink / raw)
To: emacs-devel
On 12/08/2011 09:30 PM, Carsten Mattner wrote:
> Again, totally unscientific test without real instruments.
>
> On a fresh trunk --with-ns build:
>
> paste "(insert (apply #'concat (make-list 1000000 "test:1:oops\n")))"
> to *scratch* and M-x eval-buffer: from 21.8MB to 55.8MB
>
> as this was *scratch*, open ~/.bashrc in another buffer and kill both
> and it's down to 44.4MB
>
> M-x garbage-collect 32.9MB
>
> M-x garbage-collect, M-x garbage-collect: 29.2MB
You should say M-x compilation-minor-mode for *scratch* - that's the point
of this test case.
Dmitry
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-09 3:39 ` Dmitry Antipov
@ 2011-12-09 13:52 ` Carsten Mattner
0 siblings, 0 replies; 87+ messages in thread
From: Carsten Mattner @ 2011-12-09 13:52 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: emacs-devel
On Fri, Dec 9, 2011 at 4:39 AM, Dmitry Antipov <dmantipov@yandex.ru> wrote:
> On 12/08/2011 09:30 PM, Carsten Mattner wrote:
>
>> Again, totally unscientific test without real instruments.
>>
>> On a fresh trunk --with-ns build:
>>
>> paste "(insert (apply #'concat (make-list 1000000 "test:1:oops\n")))"
>> to *scratch* and M-x eval-buffer: from 21.8MB to 55.8MB
>>
>> as this was *scratch*, open ~/.bashrc in another buffer and kill both
>> and it's down to 44.4MB
>>
>> M-x garbage-collect 32.9MB
>>
>> M-x garbage-collect, M-x garbage-collect: 29.2MB
>
>
> You should say M-x compilation-minor-mode for *scratch* - that's the point
> of this test case.
Oops, sorry. New test results follow.
Emacs.app Darwin 10.7.2 32-bit binary
fresh start: 20.9MB
M-x compilation-minor-mode: 21.6MB
paste test elisp code: 21.6MB
M-x eval-buffer: 52.8MB
M-x garbage-collect: 41.4MB
New empty buffer: 41.4MB
kill-buffer in compilation-minor-mode: 29.9MB
kill-buffer the new buffer: 30.0MB
M-x garbage-collect
M-x garbage-collect
M-x garbage-collect
M-x garbage-collect: 30.0MB
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-06 9:35 ` Carsten Mattner
2011-12-06 10:24 ` Dmitry Antipov
@ 2011-12-06 13:12 ` Eli Zaretskii
1 sibling, 0 replies; 87+ messages in thread
From: Eli Zaretskii @ 2011-12-06 13:12 UTC (permalink / raw)
To: Carsten Mattner; +Cc: ofv, emacs-devel
> Date: Tue, 6 Dec 2011 10:35:09 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
>
> Any ready-made instrumentation to reveal what's going on for find
> the root cause or explanation of what's going?
I'm not aware of any existing instrumentation. Maybe someone else can
help.
Failing that, perhaps some tool that can show detailed memory usage
and allows to find, for each memory region, its corresponding C
symbol, could be used to find out which one(s) are holding on to the
supposedly free memory in your use case.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-06 5:08 ` Eli Zaretskii
2011-12-06 9:35 ` Carsten Mattner
@ 2011-12-06 16:28 ` Óscar Fuentes
2011-12-06 19:53 ` Stefan Monnier
1 sibling, 1 reply; 87+ messages in thread
From: Óscar Fuentes @ 2011-12-06 16:28 UTC (permalink / raw)
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> Just for the record: a *compile* buffer ended with 10M lines of
>> diagnostics emitted by a compiler. The emacs process jumped from 60MB to
>> 526MB of RES memory.
>
> On what OS?
Kubuntu 11.8 Linux version 3.0.0-13-generic #22-Ubuntu SMP x86_64.
> And was the size of the buffer comparable with 520MB?
Dunno. With the same emacs process (which is running as a daemon) after
repeating the steps that created that monster *compile* buffer I got:
Size, as reported by ibuffer: 29843302
Size of the file after saving the buffer's contents: 29843327
Number of lines: 1053239 (not 10M as reported on my previous msg)
The RES memory used by emacs stayed at 526MB.
Another issue is that if you press M-> (end-of-buffer) on that *compile*
buffer emacs uses 100% cpu and does freezes, apparently. After a while
(half a minute or so) pressing C-g makes emacs alive again and the point
is at the end of the *compile* buffer. Possibly it was fontifying the
buffer, as the last half of it is not fontified. After this, the RES
memory used by emacs increased to 554MB (from 526). A bit later it went
back to 526MB. Jumping at random on the buffer for a while increased the
memory usage to 533MB.
Again, killing that *compile* buffer makes no difference on the memory
used by emacs as reported by htop.
>> That was yesterday, and emacs keeps retaining that memory.
>
> Are you saying that you killed the *compilation* buffer and Emacs
> memory footprint didn't change at all? I find that hard to believe.
I'm writing this message on that very same emacs process. Right now it
has 60 buffers, all of them with a size below 50KB and most below
10KB. As reported by `htop', the process is using 533MB of RES memory
and 630MB of VIRT memory.
>> I guess that as the buffer grew it was reallocated again and
>> again. Obviously fragmentation is at play here.
>
> If ralloc.c is used on the system where you did that, fragmentation
> should be prevented, especially in buffer text reallocations. If
> ralloc.c is not used, I believe Emacs relies on the system's memory
> allocation to avoid fragmentation (that's why ralloc.c is not needed
> on those systems).
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-06 16:28 ` Óscar Fuentes
@ 2011-12-06 19:53 ` Stefan Monnier
2011-12-11 17:49 ` Nix
2011-12-15 3:52 ` Tim Connors
0 siblings, 2 replies; 87+ messages in thread
From: Stefan Monnier @ 2011-12-06 19:53 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: emacs-devel
> I'm writing this message on that very same emacs process. Right now it
> has 60 buffers, all of them with a size below 50KB and most below
> 10KB. As reported by `htop', the process is using 533MB of RES memory
> and 630MB of VIRT memory.
Nothing of what you say sounds worrisome: apparently you now have around
half a GB of memory allocated for use by Lisp data. Most likely the
majority of it is considered by Emacs as "free for reuse", but it's not
returned to the OS because that is only done in "big chunks" (typically
10KB or so) and none of the big chunks are 100% free (they all contain
at least one non-free object).
Some of that memory may also belong to malloc rather than to Emacs:
Emacs did pass it to `free', but the malloc library decided that it's
not worth returning those elements to the OS.
Of course, it may also be that we have an actual leak (i.e. some of that
memory was neither returned to malloc, nor is it still managed by
Emacs). But as long as you don't have evidence of a leak, I'd suggest
you move on, because there's really not much we can do about the above
problem (short of rewriting the whole memory management to make it
compacting).
Stefan
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-12-06 19:53 ` Stefan Monnier
@ 2011-12-11 17:49 ` Nix
2011-12-15 3:52 ` Tim Connors
1 sibling, 0 replies; 87+ messages in thread
From: Nix @ 2011-12-11 17:49 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Óscar Fuentes, emacs-devel
On 6 Dec 2011, Stefan Monnier stated:
>> I'm writing this message on that very same emacs process. Right now it
>> has 60 buffers, all of them with a size below 50KB and most below
>> 10KB. As reported by `htop', the process is using 533MB of RES memory
>> and 630MB of VIRT memory.
>
> Nothing of what you say sounds worrisome: apparently you now have around
> half a GB of memory allocated for use by Lisp data. Most likely the
> majority of it is considered by Emacs as "free for reuse", but it's not
> returned to the OS because that is only done in "big chunks" (typically
> 10KB or so) and none of the big chunks are 100% free (they all contain
> at least one non-free object).
More generally, unless this is the *last* such chunk allocated, it's not
going to be returned to the OS (as 10Kb regions are small enough that
they're going to come from brk space on every malloc I've ever heard of,
not malloc space).
It might be worth trying to boost that 10Kb 'big' chunk to 2Mb or
something. That'll force mmap() allocation on a lot of recent Linux
systems. (Of course, if you have tens of thousands of those, you can run
into kernel limits: but if your Emacs is using that much memory, you
have bigger problems.)
--
NULL && (void)
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-06 19:53 ` Stefan Monnier
2011-12-11 17:49 ` Nix
@ 2011-12-15 3:52 ` Tim Connors
2011-12-15 4:09 ` Eli Zaretskii
2011-12-16 21:55 ` Stefan Monnier
1 sibling, 2 replies; 87+ messages in thread
From: Tim Connors @ 2011-12-15 3:52 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Óscar Fuentes, emacs-devel
On Tue, 6 Dec 2011, Stefan Monnier wrote:
> > I'm writing this message on that very same emacs process. Right now it
> > has 60 buffers, all of them with a size below 50KB and most below
> > 10KB. As reported by `htop', the process is using 533MB of RES memory
> > and 630MB of VIRT memory.
>
> Nothing of what you say sounds worrisome: apparently you now have around
> half a GB of memory allocated for use by Lisp data. Most likely the
> majority of it is considered by Emacs as "free for reuse", but it's not
> returned to the OS because that is only done in "big chunks" (typically
> 10KB or so) and none of the big chunks are 100% free (they all contain
> at least one non-free object).
> Some of that memory may also belong to malloc rather than to Emacs:
> Emacs did pass it to `free', but the malloc library decided that it's
> not worth returning those elements to the OS.
> Of course, it may also be that we have an actual leak (i.e. some of that
> memory was neither returned to malloc, nor is it still managed by
> Emacs). But as long as you don't have evidence of a leak, I'd suggest
> you move on, because there's really not much we can do about the above
> problem (short of rewriting the whole memory management to make it
> compacting).
I recently switched over to Emacs, from XEmacs, porting my .config files
over as necessary. I am used to being able to run XEmacs for months on
end, with XEmacs's gnuclient, and having hundreds of buffers and dozens of
frames open. The XEmacs process would sometimes take 100M or so resident,
and if I opened a big file and tried to fontify it, then naturally usage
would increase. Some of this would be returned to the OS, some of it
wouldn't, when I closed buffers. I lived with that because I didn't tend
to stupidly open big files and fontify them too often.
But right now, having had emacs up for a few days, and only opening 10
small files with the aid of emacsclient, emacs's RSS is 130M. It had
climbed up to 400M before I most recently killed it.
What's the differences between emacs's and xemacs's allocators?
By the way, the dismissal of this being a real problem because emacs can
always reuse the fragmented memory either
1) ignores the fact that computers are general purpose and can run other
programs simultaneously (some of them being rather high quality bloatware
like mozilla), or
2) takes the view that emacs is an entire operating system, and there's no
need to run anything else, a little too seriously
--
Tim Connors
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-15 3:52 ` Tim Connors
@ 2011-12-15 4:09 ` Eli Zaretskii
2011-12-15 4:38 ` Tim Connors
2011-12-15 4:50 ` Óscar Fuentes
2011-12-16 21:55 ` Stefan Monnier
1 sibling, 2 replies; 87+ messages in thread
From: Eli Zaretskii @ 2011-12-15 4:09 UTC (permalink / raw)
To: Tim Connors; +Cc: ofv, monnier, emacs-devel
> Date: Thu, 15 Dec 2011 14:52:23 +1100 (EST)
> From: Tim Connors <tim.w.connors@gmail.com>
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
>
> But right now, having had emacs up for a few days, and only opening 10
> small files with the aid of emacsclient, emacs's RSS is 130M. It had
> climbed up to 400M before I most recently killed it.
What version of Emacs is that, and on which OS?
FWIW, my Emacs runs for many weeks if not months, has about 250 to 300
buffers of various sizes, and never exceeds 200MB (usually levels out
at 170MB).
> By the way, the dismissal of this being a real problem because emacs can
> always reuse the fragmented memory either
I don't think there's much fragmented memory in real-life use (barring
bugs). The test cases that exhibited a lot of fragmentation are all
toy examples that don't really happen.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-15 4:09 ` Eli Zaretskii
@ 2011-12-15 4:38 ` Tim Connors
2011-12-15 5:52 ` Eli Zaretskii
2011-12-15 4:50 ` Óscar Fuentes
1 sibling, 1 reply; 87+ messages in thread
From: Tim Connors @ 2011-12-15 4:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ofv, monnier, emacs-devel
On Thu, 15 Dec 2011, Eli Zaretskii wrote:
> > Date: Thu, 15 Dec 2011 14:52:23 +1100 (EST)
> > From: Tim Connors <tim.w.connors@gmail.com>
> > Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> >
> > But right now, having had emacs up for a few days, and only opening 10
> > small files with the aid of emacsclient, emacs's RSS is 130M. It had
> > climbed up to 400M before I most recently killed it.
>
> What version of Emacs is that, and on which OS?
debian stable, debian package version 23.2+1-7
(version) returns:
GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
2011-10-26 on trouble, modified by Debian
I should be able to upgrade to testing's 23.3+1-4 pretty easily when I
have a spare moment, but I don't imagine there's too many patch
differences between the 2 versions.
--
Tim Connors
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-15 4:38 ` Tim Connors
@ 2011-12-15 5:52 ` Eli Zaretskii
0 siblings, 0 replies; 87+ messages in thread
From: Eli Zaretskii @ 2011-12-15 5:52 UTC (permalink / raw)
To: Tim Connors; +Cc: ofv, monnier, emacs-devel
> Date: Thu, 15 Dec 2011 15:38:24 +1100 (EST)
> From: Tim Connors <tim.w.connors@gmail.com>
> cc: monnier@IRO.UMontreal.CA, ofv@wanadoo.es, emacs-devel@gnu.org
>
> On Thu, 15 Dec 2011, Eli Zaretskii wrote:
>
> > > Date: Thu, 15 Dec 2011 14:52:23 +1100 (EST)
> > > From: Tim Connors <tim.w.connors@gmail.com>
> > > Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> > >
> > > But right now, having had emacs up for a few days, and only opening 10
> > > small files with the aid of emacsclient, emacs's RSS is 130M. It had
> > > climbed up to 400M before I most recently killed it.
> >
> > What version of Emacs is that, and on which OS?
>
> debian stable, debian package version 23.2+1-7
>
> (version) returns:
>
> GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
> 2011-10-26 on trouble, modified by Debian
Next question: what optional packages are loaded? (AFAIR, debian
systems are notorious for loading gobs of stuff in their site init
files.) Also, what memory footprint do you get if you start from
"emacs -Q" and then load all those "10 small files" you mentioned in
the original report? If you get a comparably large RSS, try to find
out which of the files/modes has the greatest effect on the memory
footprint.
Finally, can you recollect or retrace what caused the RSS to climb
from 130MB to 400MB?
> I should be able to upgrade to testing's 23.3+1-4 pretty easily when I
> have a spare moment, but I don't imagine there's too many patch
> differences between the 2 versions.
I would suggest to try the latest pretest of Emacs 24 (24.0.92 as of
this writing). The Emacs 23 branch is closed for development, and
unless someone reports some catastrophe with the 23.x series, will not
be reopen. Any memory-related bugs we find will be fixed in Emacs 24,
so it makes sense to first establish if the same problems exist there.
Thanks.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-15 4:09 ` Eli Zaretskii
2011-12-15 4:38 ` Tim Connors
@ 2011-12-15 4:50 ` Óscar Fuentes
2011-12-15 6:04 ` Eli Zaretskii
1 sibling, 1 reply; 87+ messages in thread
From: Óscar Fuentes @ 2011-12-15 4:50 UTC (permalink / raw)
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> But right now, having had emacs up for a few days, and only opening 10
>> small files with the aid of emacsclient, emacs's RSS is 130M. It had
>> climbed up to 400M before I most recently killed it.
>
> What version of Emacs is that, and on which OS?
>
> FWIW, my Emacs runs for many weeks if not months, has about 250 to 300
> buffers of various sizes, and never exceeds 200MB (usually levels out
> at 170MB).
I have a similar experience.
>> By the way, the dismissal of this being a real problem because emacs can
>> always reuse the fragmented memory either
>
> I don't think there's much fragmented memory in real-life use (barring
> bugs). The test cases that exhibited a lot of fragmentation are all
> toy examples that don't really happen.
The case I described was real, although seldom happens here. I can think
of typical scenarios where buffer size grows to large sizes: ERC
sessions, files monitored with auto-revert(-tail)-mode... Even cases
where the user makes a mistake that creates huge buffers (visiting a
GNUs group with tens of thousands on unread messages, for instance.)
Taking a selfish stance, I don't care about this problem because it is
not harming me, but your response and Stefan's looks a lot like hand
waving. Yes, it probably is hard to fix and there are more profitably
tasks, but it *is* a real problem, not something a user made up for
chatting about memory allocators on emacs-devel.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-15 4:50 ` Óscar Fuentes
@ 2011-12-15 6:04 ` Eli Zaretskii
0 siblings, 0 replies; 87+ messages in thread
From: Eli Zaretskii @ 2011-12-15 6:04 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: emacs-devel
> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 15 Dec 2011 05:50:17 +0100
>
> > I don't think there's much fragmented memory in real-life use (barring
> > bugs). The test cases that exhibited a lot of fragmentation are all
> > toy examples that don't really happen.
>
> The case I described was real, although seldom happens here.
OK, let's agree these cases are rare.
> I can think of typical scenarios where buffer size grows to large
> sizes: ERC sessions, files monitored with
> auto-revert(-tail)-mode... Even cases where the user makes a mistake
> that creates huge buffers (visiting a GNUs group with tens of
> thousands on unread messages, for instance.)
It has never been proven that just growing a buffer in small chunks
has this effect. Stefan thinks the reason is intervals. I'm not sure
he is right (but I'm not an expert on this). I want to play with the
examples posted here to trace what they do to memory allocation, but I
need to find time to do it. If someone has time and motivation, it
would help to trace through the various memory-allocation routines in
those cases and report the results.
FWIW, I always have at least one buffer in auto-revert-mode (it
watches my .bzr.log file), and the memory footprint is still quite
moderate, see my previous message.
> Taking a selfish stance, I don't care about this problem because it is
> not harming me, but your response and Stefan's looks a lot like hand
> waving.
I don't understand where you see hand-waving. Reports about excessive
memory consumption in real-life usage, like in Emacs running normally
doing the usual stuff, are taken very seriously. They are hard to
track down, especially if they happen on systems whose users cannot
provide hard facts because they lack the ability to dig into the code
with a debugger. This could explain slow progress, or no progress at
all, in solving these problems. But no one hand-waves them under the
carpet; saying so is simply unfair.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-15 3:52 ` Tim Connors
2011-12-15 4:09 ` Eli Zaretskii
@ 2011-12-16 21:55 ` Stefan Monnier
2011-12-17 17:40 ` Nix
2011-12-18 15:13 ` Dmitry Antipov
1 sibling, 2 replies; 87+ messages in thread
From: Stefan Monnier @ 2011-12-16 21:55 UTC (permalink / raw)
To: Tim Connors; +Cc: Óscar Fuentes, emacs-devel
> But right now, having had emacs up for a few days, and only opening 10
> small files with the aid of emacsclient, emacs's RSS is 130M. It had
> climbed up to 400M before I most recently killed it.
400M definitely sounds like a bug.
> What's the differences between Emacs's and XEmacs's allocators?
I don't think the source of your problem/difference is in the allocator.
> By the way, the dismissal of this being a real problem because Emacs can
> always reuse the fragmented memory either
I don't really dismiss it. My point is rather the following:
- Many memory problems are misdiagnosed as fragmentation problems, where
the real cause is either inefficient memory use, or memory leaks.
- Real fragmentation problems exist but are fairly rare.
- In some "fragmentation" cases, the Emacs process holds on to memory
without any good reason, i.e. it's been "free"d but the malloc library
does not want or can't return it to the OS because it did not use mmap
to allocate it. This can be fixed, but this memory would really be
unused; it can still appear in RSS but only because the memory
pressure hasn't yet bumped it out of RAM. IOW these cases may show
high memory use in terms of VSZ or RSS but fixing them is low priority
because their only direct cost is use of of swap space.
- Fixing the remaining real fragmentation problems probably requires
a different allocator that can move objects to compact the memory
space. Maybe such an allocator can be retrofitted into Emacs
(e.g. a mostly-copying allocator), but noone has tried it yet
(probably because the outcome is hard to predict, the problem it
attempts to fix only occurs rather rarely, and it can be difficult to
ensure that it doesn't affect negatively the more common cases).
So, I know such problems exist in real life, and I would be happy to
accept patches that fix them, but it's not very high on my list
of priorities.
Stefan
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-12-16 21:55 ` Stefan Monnier
@ 2011-12-17 17:40 ` Nix
2011-12-18 15:13 ` Dmitry Antipov
1 sibling, 0 replies; 87+ messages in thread
From: Nix @ 2011-12-17 17:40 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Óscar Fuentes, Tim Connors, emacs-devel
On 16 Dec 2011, Stefan Monnier verbalised:
>> But right now, having had emacs up for a few days, and only opening 10
>> small files with the aid of emacsclient, emacs's RSS is 130M. It had
>> climbed up to 400M before I most recently killed it.
>
> 400M definitely sounds like a bug.
Yeah, I think we can say there are still memory problems.
My Gnus emacs:
STIME RSS VSZ
Dec04 1008240 1308036
-> ((2401615 . 1487819) (88772 . 913) (73876 . 16943) 90573999 2807511
(7934 . 6904) (62114 . 9815) (490992 . 230843))
My work emacs:
Dec04 358552 631872
-> ((1723889 . 1204243) (985751 . 0) (36577 . 18323) 22141303 1094138
(871 . 5908) (152632 . 5033) (1217993 . 74149))
Note that the one with the biggest buffers and most symbols is the one
that is using the least insane amount of memory. (Though nobody can beat
Gnus for massive strings; 90Mb!!)
So the encrypted IMAP memory leak fixes haven't fixed things entirely :(
--
NULL && (void)
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-12-16 21:55 ` Stefan Monnier
2011-12-17 17:40 ` Nix
@ 2011-12-18 15:13 ` Dmitry Antipov
2011-12-19 1:34 ` Stefan Monnier
1 sibling, 1 reply; 87+ messages in thread
From: Dmitry Antipov @ 2011-12-18 15:13 UTC (permalink / raw)
To: emacs-devel
On 12/17/2011 01:55 AM, Stefan Monnier wrote:
> - Many memory problems are misdiagnosed as fragmentation problems, where
> the real cause is either inefficient memory use, or memory leaks.
> - Real fragmentation problems exist but are fairly rare.
It would be nice to have a built-in (optionally selected at configure time)
method to provide a 'shot' of the heap to see how it's (mis)used. It's also
interesting whether it's possible to write a set of gdb macros for doing
something similar.
> - In some "fragmentation" cases, the Emacs process holds on to memory
> without any good reason, i.e. it's been "free"d but the malloc library
> does not want or can't return it to the OS because it did not use mmap
> to allocate it. This can be fixed, but this memory would really be
> unused; it can still appear in RSS but only because the memory
> pressure hasn't yet bumped it out of RAM. IOW these cases may show
> high memory use in terms of VSZ or RSS but fixing them is low priority
> because their only direct cost is use of of swap space.
IIUC, this is not true, at least for Linux (see how zap_pte_range() updates
MM_ANONPAGES RSS counter; it's done when munmap() happens). Unmapped
(but still resident in RAM) pages aren't accounted as RSS of any process;
they're accounted separately and amount of space occupied by such pages is
'Active(anon)' in /proc/meminfo.
> - Fixing the remaining real fragmentation problems probably requires
> a different allocator that can move objects to compact the memory
> space. Maybe such an allocator can be retrofitted into Emacs
> (e.g. a mostly-copying allocator), but noone has tried it yet
> (probably because the outcome is hard to predict, the problem it
> attempts to fix only occurs rather rarely, and it can be difficult to
> ensure that it doesn't affect negatively the more common cases).
It's not so hard to predict the memory-saving benefits of copying or
compacting collector - ideally such a collector should free everything
which is on a free lists in current collector, so an output of
garbage-collect may be used as a rough estimate of how much data can
be compacted. In my measurements, the typical amount of space which is
hold of a free lists is ~3-5% of total heap size; it's reasonable to expect
that copying/compacting collector may also decrease an overall heap
fragmentation, which may give a few more percents. Anyway, ~5% isn't
convincing enough to start a hard work on a new GC; instead, I believe
that some minor optimization of current algorithm and Lisp data representation
(vector allocation, compact or 'immediate' strings and something like cdr-coding
or unrolled lists) may give comparable, or even better, effect in the sense
of memory consumption.
Dmitry
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-12-18 15:13 ` Dmitry Antipov
@ 2011-12-19 1:34 ` Stefan Monnier
2011-12-19 8:28 ` Dmitry Antipov
0 siblings, 1 reply; 87+ messages in thread
From: Stefan Monnier @ 2011-12-19 1:34 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: emacs-devel
>> - Many memory problems are misdiagnosed as fragmentation problems, where
>> the real cause is either inefficient memory use, or memory leaks.
>> - Real fragmentation problems exist but are fairly rare.
> It would be nice to have a built-in (optionally selected at configure time)
> method to provide a 'shot' of the heap to see how it's (mis)used. It's also
> interesting whether it's possible to write a set of gdb macros for doing
> something similar.
`garbage-collect' is supposed to give that info. At least it does give
info about the data that's kept under alloc.c's control because
of fragmentation (these are counted as "free cells").
>> - In some "fragmentation" cases, the Emacs process holds on to memory
>> without any good reason, i.e. it's been "free"d but the malloc library
>> does not want or can't return it to the OS because it did not use mmap
>> to allocate it. This can be fixed, but this memory would really be
>> unused; it can still appear in RSS but only because the memory
>> pressure hasn't yet bumped it out of RAM. IOW these cases may show
>> high memory use in terms of VSZ or RSS but fixing them is low priority
>> because their only direct cost is use of of swap space.
> IIUC, this is not true, at least for Linux (see how zap_pte_range() updates
> MM_ANONPAGES RSS counter; it's done when munmap() happens). Unmapped
> (but still resident in RAM) pages aren't accounted as RSS of any process;
> they're accounted separately and amount of space occupied by such pages is
> 'Active(anon)' in /proc/meminfo.
Re-read what I wrote: I'm talking about the case where alloc.c free'd the
data, but malloc did not munmap it.
>> - Fixing the remaining real fragmentation problems probably requires
>> a different allocator that can move objects to compact the memory
>> space. Maybe such an allocator can be retrofitted into Emacs
>> (e.g. a mostly-copying allocator), but noone has tried it yet
>> (probably because the outcome is hard to predict, the problem it
>> attempts to fix only occurs rather rarely, and it can be difficult to
>> ensure that it doesn't affect negatively the more common cases).
> It's not so hard to predict the memory-saving benefits of copying or
> compacting collector - ideally such a collector should free everything
It's easy to predict what it does in terms of "what is the benefit when
I have a lot of fragmentation". It's much more difficult to predict
what it does in terms of "how is it going to affect Emacs's behavior for
those 99% cases where it currently works just fine".
> hold of a free lists is ~3-5% of total heap size; it's reasonable to expect
> that copying/compacting collector may also decrease an overall heap
> fragmentation, which may give a few more percents. Anyway, ~5% isn't
> convincing enough to start a hard work on a new GC; instead, I believe
I see we agree.
> that some minor optimization of current algorithm and Lisp data
> representation (vector allocation, compact or 'immediate' strings and
> something like cdr-coding or unrolled lists) may give comparable, or
> even better, effect in the sense of memory consumption.
I agree that we're probably going to see better overall results by
improving general memory use than by trying to attack
fragmentation problems.
Stefan
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-12-19 1:34 ` Stefan Monnier
@ 2011-12-19 8:28 ` Dmitry Antipov
2011-12-19 11:26 ` Stefan Monnier
0 siblings, 1 reply; 87+ messages in thread
From: Dmitry Antipov @ 2011-12-19 8:28 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]
On 12/19/2011 05:34 AM, Stefan Monnier wrote:
> `garbage-collect' is supposed to give that info. At least it does give
> info about the data that's kept under alloc.c's control because
> of fragmentation (these are counted as "free cells").
I would like to propose a function which explicitly says how much free memory
the Emacs process holds. It's especially useful when there is a way to ask
system malloc about how much free memory is in the heap. This may be helpful
to distinguish real heap fragmentation from memory leaks and other misuses -
if the sum of values returned by 'memory-free' is, say, 10% of heap size,
then the real fragmentation enters into the game.
> Re-read what I wrote: I'm talking about the case where alloc.c free'd the
> data, but malloc did not munmap it.
I read it as 'even if we will fix allocation to use mmap and munmap, unmapped
memory would really be unused and still appear in process RSS, thus giving
higher RSS value than the process really has, until the memory pressure bump
it out of RAM'. That was obviously incorrect because RSS is recalculated
each time when mmap/mremap/munmap/brk is (successfully) called.
> It's easy to predict what it does in terms of "what is the benefit when
> I have a lot of fragmentation". It's much more difficult to predict
> what it does in terms of "how is it going to affect Emacs's behavior for
> those 99% cases where it currently works just fine".
There is an interesting research paper about moving PLT Scheme from mark-sweep
GC to an accurate copying GC: http://www.cs.utah.edu/plt/publications/ismm09-rwrf.pdf.
In short, it's said about getting rid out of the most fragmentation issues at the cost
of 10-20% slowdown (although I consider their approach as practically inapplicable
beyond the pure research efforts).
> I agree that we're probably going to see better overall results by
> improving general memory use than by trying to attack
> fragmentation problems.
Among this list's subscribers, Nix <nix@[hidden]> is constantly reporting an enormous
memory usage caused by Gnus. Since I newer seen such a heap usage in my own test cases,
I offered him a 'cumulative' patch (against 24.0.92) with both immediate strings and
block vector allocator. He has said that we can expect the first results after Christmas :-).
Dmitry
[-- Attachment #2: memory_free.patch --]
[-- Type: text/plain, Size: 2175 bytes --]
=== modified file 'src/alloc.c'
--- src/alloc.c 2011-12-12 05:32:49 +0000
+++ src/alloc.c 2011-12-19 06:06:04 +0000
@@ -75,6 +75,10 @@
#define MMAP_MAX_AREAS 100000000
+/* Value of mallinfo ().fordblks as seen at the end of last GC. */
+
+static int bytes_free;
+
#else /* not DOUG_LEA_MALLOC */
/* The following come from gmalloc.c. */
@@ -5271,6 +5275,10 @@
total[7] = Fcons (make_number (total_strings),
make_number (total_free_strings));
+#ifdef DOUG_LEA_MALLOC
+ bytes_free = mallinfo ().fordblks;
+#endif
+
#if GC_MARK_STACK == GC_USE_GCPROS_CHECK_ZOMBIES
{
/* Compute average percentage of zombies. */
@@ -6221,6 +6229,33 @@
return end;
}
+DEFUN ("memory-free", Fmemory_free, Smemory_free, 0, 0, 0,
+ doc: /* Return a list of two counters that measure how much free
+memory is hold by the Emacs process. Both counters are
+in KBytes. First counter shows how much memory holds in
+a free lists maintained by the Emacs itself. Second counter
+shows how much free memory is in the heap. If the second
+counter is zero, heap statistics is not available. */)
+ (void)
+{
+ Lisp_Object data[2];
+
+ data[0] = make_number
+ (min (MOST_POSITIVE_FIXNUM,
+ (total_free_conses * sizeof (struct Lisp_Cons) +
+ total_free_markers * sizeof (union Lisp_Misc) +
+ total_free_symbols * sizeof (struct Lisp_Symbol) +
+ total_free_floats * sizeof (struct Lisp_Float) +
+ total_free_intervals * sizeof (struct interval) +
+ total_free_strings * sizeof (struct Lisp_String)) / 1024));
+#ifdef DOUG_LEA_MALLOC
+ data[1] = make_number (min (MOST_POSITIVE_FIXNUM, bytes_free / 1024));
+#else
+ data[1] = make_number (0);
+#endif
+ return Flist (2, data);
+}
+
DEFUN ("memory-use-counts", Fmemory_use_counts, Smemory_use_counts, 0, 0, 0,
doc: /* Return a list of counters that measure how much consing there has been.
Each of these counters increments for a certain kind of object.
@@ -6474,6 +6509,7 @@
defsubr (&Spurecopy);
defsubr (&Sgarbage_collect);
defsubr (&Smemory_limit);
+ defsubr (&Smemory_free);
defsubr (&Smemory_use_counts);
#if GC_MARK_STACK == GC_USE_GCPROS_CHECK_ZOMBIES
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-12-19 8:28 ` Dmitry Antipov
@ 2011-12-19 11:26 ` Stefan Monnier
2012-01-23 16:49 ` Nix
0 siblings, 1 reply; 87+ messages in thread
From: Stefan Monnier @ 2011-12-19 11:26 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: emacs-devel
>> `garbage-collect' is supposed to give that info. At least it does give
>> info about the data that's kept under alloc.c's control because
>> of fragmentation (these are counted as "free cells").
> I would like to propose a function which explicitly says how much free memory
> the Emacs process holds.
For the part that alloc.c holds, the "memory-usage" package in ELPA
should do the trick (or can be improved to do it).
> It's especially useful when there is a way to ask system malloc about
> how much free memory is in the heap.
It'd be great to add this data when available, indeed. Patch welcome.
> This may be helpful to distinguish real heap fragmentation from memory
> leaks and other misuses - if the sum of values returned by
> 'memory-free' is, say, 10% of heap size, then the real fragmentation
> enters into the game.
It may also be important to try and keep track of other allocations,
which are not under alloc.c's control (e.g. allocations performed by
GUI libraries).
>> I agree that we're probably going to see better overall results by
>> improving general memory use than by trying to attack
>> fragmentation problems.
> Among this list's subscribers, Nix <nix@[hidden]> is constantly
> reporting an enormous memory usage caused by Gnus.
I think we still have a leak there somewhere.
Stefan
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Memory again
2011-12-19 11:26 ` Stefan Monnier
@ 2012-01-23 16:49 ` Nix
2012-01-25 16:19 ` Ted Zlatanov
0 siblings, 1 reply; 87+ messages in thread
From: Nix @ 2012-01-23 16:49 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
On 19 Dec 2011, Stefan Monnier outgrape:
>>> I agree that we're probably going to see better overall results by
>>> improving general memory use than by trying to attack
>>> fragmentation problems.
>> Among this list's subscribers, Nix <nix@[hidden]> is constantly
>> reporting an enormous memory usage caused by Gnus.
>
> I think we still have a leak there somewhere.
Confirmed. With Dmitry's immediate-string patch (which works perfectly
otherwise):
RSS VSZ USER STIME
720696 1008752 gnus Jan07
242740 525592 hacking 2011
Despite running for less than half the time, the Gnus Emacs is twice the
size. It bloats more slowly than without Dmitry's patch, but it still
bloats.
I suspect that the only way I'll be able to provide a reproducible
recipe for this is to instrument Emacs to record all allocations and GCs
and when they happen, so that someone else can play this back to observe
WTF is going on. Doing this compactly enough to run over weeks without
serving as a DoS-attack on my own system may be... interesting. I
haven't done any work toward this yet though.
--
NULL && (void)
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2012-01-23 16:49 ` Nix
@ 2012-01-25 16:19 ` Ted Zlatanov
0 siblings, 0 replies; 87+ messages in thread
From: Ted Zlatanov @ 2012-01-25 16:19 UTC (permalink / raw)
To: emacs-devel
On Mon, 23 Jan 2012 16:49:37 +0000 Nix <nix@esperi.org.uk> wrote:
N> On 19 Dec 2011, Stefan Monnier outgrape:
>>>> I agree that we're probably going to see better overall results by
>>>> improving general memory use than by trying to attack
>>>> fragmentation problems.
>>> Among this list's subscribers, Nix <nix@[hidden]> is constantly
>>> reporting an enormous memory usage caused by Gnus.
>>
>> I think we still have a leak there somewhere.
N> Confirmed. With Dmitry's immediate-string patch (which works perfectly
N> otherwise):
N> RSS VSZ USER STIME
N> 720696 1008752 gnus Jan07
N> 242740 525592 hacking 2011
N> Despite running for less than half the time, the Gnus Emacs is twice the
N> size. It bloats more slowly than without Dmitry's patch, but it still
N> bloats.
N> I suspect that the only way I'll be able to provide a reproducible
N> recipe for this is to instrument Emacs to record all allocations and GCs
N> and when they happen, so that someone else can play this back to observe
N> WTF is going on. Doing this compactly enough to run over weeks without
N> serving as a DoS-attack on my own system may be... interesting. I
N> haven't done any work toward this yet though.
Some valgrind recipes were posted that may help. Can you try them?
I could not put together a test case to cause memory bloat with GnuTLS
usage alone. Do you want to try that? If such a test case can be shown
to cause bloat without Gnus, we'll know where to look.
Ted
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-26 14:58 ` Carsten Mattner
2011-11-26 16:23 ` Eli Zaretskii
@ 2011-11-26 17:54 ` Dmitry Antipov
2011-11-26 18:47 ` martin rudalics
2011-11-26 19:09 ` Carsten Mattner
2011-11-28 4:27 ` Stefan Monnier
2 siblings, 2 replies; 87+ messages in thread
From: Dmitry Antipov @ 2011-11-26 17:54 UTC (permalink / raw)
To: emacs-devel
On 11/26/2011 06:58 PM, Carsten Mattner wrote:
> Allow me to be naive and ask this: what about compaction?
Compaction implies the moving of live objects, which means that you
should be able to find _all_ pointers to such objects and update them.
Emacs GC has no such features, but it's technically possible
to enhance mark/sweep GC to do some heap compaction.
> Would the allocator in use fragment the overall system memory
> space if it frees more aggressively?
If you want to ask 'if we will run GC more often, will it reduce
heap fragmentation', the answer is most probably 'no'. You can try
to play with 'gc-cons-threshold' and 'gc-cons-percentage' and see
what happens. But, in general, heap fragmentation issues can't be
solved this way.
Other possible meanings of 'more aggressively' makes no sense for
simple (non-generational, non-incremental) mark/sweep GC since it
_always _ marks all live data and _always_ sweeps the whole
Lisp data regions of the heap.
If you're looking for good introduction to GC stuff, I would
recommend ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps.
Dmitry
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-26 17:54 ` Dmitry Antipov
@ 2011-11-26 18:47 ` martin rudalics
2011-11-26 19:09 ` Carsten Mattner
1 sibling, 0 replies; 87+ messages in thread
From: martin rudalics @ 2011-11-26 18:47 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: emacs-devel
> Compaction implies the moving of live objects, which means that you
> should be able to find _all_ pointers to such objects and update them.
> Emacs GC has no such features, but it's technically possible
> to enhance mark/sweep GC to do some heap compaction.
It's non-trivial to compact a heap with a conservative collector. Some
variant of Bartlett's algorithm would be needed.
martin
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-26 17:54 ` Dmitry Antipov
2011-11-26 18:47 ` martin rudalics
@ 2011-11-26 19:09 ` Carsten Mattner
1 sibling, 0 replies; 87+ messages in thread
From: Carsten Mattner @ 2011-11-26 19:09 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: emacs-devel
On Sat, Nov 26, 2011 at 6:54 PM, Dmitry Antipov <antipov@mvista.com> wrote:
> On 11/26/2011 06:58 PM, Carsten Mattner wrote:
>
>> Allow me to be naive and ask this: what about compaction?
>
> Compaction implies the moving of live objects, which means that you
> should be able to find _all_ pointers to such objects and update them.
> Emacs GC has no such features, but it's technically possible
> to enhance mark/sweep GC to do some heap compaction.
The GC I deal with most is Erlang's and it's using a copying gc
algo where the heaps are usually plenty and small enough
to make GC in 999 out of 1000 times to be unnoticeable that
if it's noticeable you found an inefficient piece of your own code.
I don't have as much real life experience with Sun's JVM
or other popular vms' GCs.
>> Would the allocator in use fragment the overall system memory
>> space if it frees more aggressively?
>
> If you want to ask 'if we will run GC more often, will it reduce
> heap fragmentation', the answer is most probably 'no'. You can try
> to play with 'gc-cons-threshold' and 'gc-cons-percentage' and see
> what happens. But, in general, heap fragmentation issues can't be
> solved this way.
>
> Other possible meanings of 'more aggressively' makes no sense for
> simple (non-generational, non-incremental) mark/sweep GC since it
> _always _ marks all live data and _always_ sweeps the whole
> Lisp data regions of the heap.
My question was about doing many tiny alloc/free calls and
fragmenting the kernel vm. Do applications like Emacs have to
consider that and do large as in 2x as required-but-not-available
"just-in-case-I-need-more" allocations?
> If you're looking for good introduction to GC stuff, I would
> recommend ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps.
Thanks.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Memory again
2011-11-26 14:58 ` Carsten Mattner
2011-11-26 16:23 ` Eli Zaretskii
2011-11-26 17:54 ` Dmitry Antipov
@ 2011-11-28 4:27 ` Stefan Monnier
2011-11-28 9:24 ` Carsten Mattner
2 siblings, 1 reply; 87+ messages in thread
From: Stefan Monnier @ 2011-11-28 4:27 UTC (permalink / raw)
To: Carsten Mattner; +Cc: Dmitry Antipov, emacs-devel
> Allow me to be naive and ask this: what about compaction?
Lots of work for very little benefit: the memory may not be re-usable by
the OS until Emacs exits, but it *is* reusable by Emacs, so it's largely
a non-problem.
> Would the allocator in use fragment the overall system memory
> space if it frees more aggressively?
We do not care about the "system memory". It's the OS's job ;-) And no,
Emacs does not "fragment" the system memory (whatever that can mean in
the page-based virtual-memory used by OS es these days) more than other
applications,.
> Nothing like that happened, but I had to restore some of the files as
> it was from a temporary directory. Restoring the directory made emacs
> realize the "file has changed on disk". Is this checked via a hash/checksum
> or does emacs carry along more than that?
If it says "file has changed on disk" it mean the buffer was
still around.
Stefan
^ permalink raw reply [flat|nested] 87+ messages in thread
end of thread, other threads:[~2012-01-25 16:19 UTC | newest]
Thread overview: 87+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-20 6:34 Memory again emacs user
2011-12-20 7:43 ` Eli Zaretskii
2011-12-20 12:05 ` emacs user
2011-12-20 13:04 ` Eli Zaretskii
2011-12-20 22:07 ` Jan Djärv
2011-12-21 8:07 ` Jan Djärv
2011-12-21 10:39 ` Carsten Mattner
2011-12-21 17:55 ` emacs user
2011-12-22 14:08 ` Jan Djärv
2011-12-22 14:58 ` emacs user
2011-12-22 18:54 ` emacs user
2011-12-22 19:15 ` Jan Djärv
2011-12-23 4:41 ` YAMAMOTO Mitsuharu
2012-01-17 10:04 ` emacs user
2012-01-17 10:58 ` YAMAMOTO Mitsuharu
2012-01-17 13:14 ` emacs user
2012-01-18 1:30 ` YAMAMOTO Mitsuharu
2011-12-22 23:09 ` Carsten Mattner
2011-12-23 0:39 ` Stefan Monnier
2011-12-23 10:44 ` emacs user
2012-01-05 6:13 ` emacs user
2012-01-05 22:37 ` Jan Djärv
2012-01-06 9:58 ` emacs user
2012-01-06 11:10 ` Carsten Mattner
-- strict thread matches above, loose matches on Subject: below --
2011-12-19 19:51 emacs user
2011-12-20 5:32 ` Dmitry Antipov
2012-01-06 14:28 ` Chong Yidong
2012-01-06 15:53 ` emacs user
2011-11-26 13:26 Carsten Mattner
2011-11-26 13:28 ` Carsten Mattner
2011-11-26 14:35 ` Dmitry Antipov
2011-11-26 14:48 ` Eli Zaretskii
2011-11-26 17:37 ` Dmitry Antipov
2011-11-26 20:19 ` Eli Zaretskii
2011-11-26 14:58 ` Carsten Mattner
2011-11-26 16:23 ` Eli Zaretskii
2011-11-26 19:02 ` Carsten Mattner
2011-11-26 20:31 ` Eli Zaretskii
2011-11-26 21:00 ` Eli Zaretskii
2011-11-27 10:29 ` Carsten Mattner
2011-11-27 10:43 ` Andreas Schwab
2011-11-27 13:53 ` Carsten Mattner
2011-11-27 13:11 ` Eli Zaretskii
2011-11-27 13:53 ` Carsten Mattner
2011-11-27 16:44 ` Eli Zaretskii
2011-11-27 17:37 ` Carsten Mattner
2011-11-27 17:59 ` Carsten Mattner
2011-12-06 4:02 ` Óscar Fuentes
2011-12-06 5:08 ` Eli Zaretskii
2011-12-06 9:35 ` Carsten Mattner
2011-12-06 10:24 ` Dmitry Antipov
2011-12-06 13:07 ` Eli Zaretskii
2011-12-06 13:29 ` Stefan Monnier
2011-12-06 17:20 ` Eli Zaretskii
2011-12-06 20:25 ` Stefan Monnier
2011-12-07 7:52 ` Eli Zaretskii
2011-12-07 8:15 ` Dmitry Antipov
2011-12-07 13:06 ` Eli Zaretskii
2011-12-07 14:01 ` Stefan Monnier
2011-12-08 17:30 ` Carsten Mattner
2011-12-09 3:39 ` Dmitry Antipov
2011-12-09 13:52 ` Carsten Mattner
2011-12-06 13:12 ` Eli Zaretskii
2011-12-06 16:28 ` Óscar Fuentes
2011-12-06 19:53 ` Stefan Monnier
2011-12-11 17:49 ` Nix
2011-12-15 3:52 ` Tim Connors
2011-12-15 4:09 ` Eli Zaretskii
2011-12-15 4:38 ` Tim Connors
2011-12-15 5:52 ` Eli Zaretskii
2011-12-15 4:50 ` Óscar Fuentes
2011-12-15 6:04 ` Eli Zaretskii
2011-12-16 21:55 ` Stefan Monnier
2011-12-17 17:40 ` Nix
2011-12-18 15:13 ` Dmitry Antipov
2011-12-19 1:34 ` Stefan Monnier
2011-12-19 8:28 ` Dmitry Antipov
2011-12-19 11:26 ` Stefan Monnier
2012-01-23 16:49 ` Nix
2012-01-25 16:19 ` Ted Zlatanov
2011-11-26 17:54 ` Dmitry Antipov
2011-11-26 18:47 ` martin rudalics
2011-11-26 19:09 ` Carsten Mattner
2011-11-28 4:27 ` Stefan Monnier
2011-11-28 9:24 ` Carsten Mattner
2011-11-28 15:31 ` Davis Herring
2011-11-28 21:33 ` Carsten Mattner
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.