5:49 a.m.
I ran the latest Mercurial XEmacs under valgrind for awhile tonight,
just because I really enjoy using such a slow editor. :-) When I
exited, the leak check reported some lost blocks; i.e., memory that
was malloced but not freed. The leaked memory looks to be mostly Lisp
objects. Does this imply a garbage collector leak? Here are the
relevant entries.
==6361== ERROR SUMMARY: 14794 errors from 25 contexts (suppressed: 52 from 1)
==6361== malloc/free: in use at exit: 26,271,417 bytes in 18,992 blocks.
==6361== malloc/free: 908,614 allocs, 889,622 frees, 1,259,809,322 bytes allocat
ed.
==6361== For counts of detected errors, rerun with: -v
==6361== searching for pointers to 18,992 not-freed blocks.
==6361== checked 27,435,432 bytes.
==6361==
==6361==
==6361== 1 bytes in 1 blocks are definitely lost in loss record 2 of 404
==6361== at 0x4005525: malloc (vg_replace_malloc.c:149)
==6361== by 0x702568: _XlcDefaultMapModifiers (in /usr/lib/libX11.so.6.2.0)
==6361== by 0x7025EE: XSetLocaleModifiers (in /usr/lib/libX11.so.6.2.0)
==6361== by 0x8489D63: init_x_locale (intl-x.c:51)
==6361== by 0x830681E: Fset_current_locale (intl.c:85)
==6361== by 0x81FF872: Ffuncall (eval.c:3928)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x8189F00: Fbyte_code (bytecode.c:2620)
==6361== by 0x81FE0F8: Feval (eval.c:3676)
==6361== by 0x81F7CAF: internal_catch (eval.c:1552)
==6361== by 0x818337A: execute_rare_opcode (bytecode.c:1419)
==6361== by 0x8184EA7: execute_optimized_program (bytecode.c:754)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FE3B8: Feval (eval.c:3737)
==6361== by 0x81FEF7A: Fprogn (eval.c:954)
==6361== by 0x82032AA: Fcond (eval.c:931)
==6361== by 0x81FE865: Feval (eval.c:3647)
==6361==
==6361==
==6361== 12 bytes in 3 blocks are definitely lost in loss record 35 of 404
==6361== at 0x4005525: malloc (vg_replace_malloc.c:149)
==6361== by 0x816E2AD: xmalloc (alloc.c:390)
==6361== by 0x3BD268E: __gmpz_init (in /usr/lib/sse2/libgmp.so.3.4.2)
==6361== by 0x81704AD: make_bignum (alloc.c:1427)
==6361== by 0x836321A: internal_coerce_number (number.c:478)
==6361== by 0x83640D7: promote_args (number.c:661)
==6361== by 0x81B0200: Ftimes (data.c:1648)
==6361== by 0x81FE7FD: Feval (eval.c:3703)
==6361== by 0x840BC3D: Fsetq_default (symbols.c:2146)
==6361== by 0x81FE865: Feval (eval.c:3647)
==6361== by 0x83269AD: readevalloop (lread.c:1467)
==6361== by 0x832A6F0: Fload_internal (lread.c:768)
==6361== by 0x81FF980: Ffuncall (eval.c:3928)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361==
==6361==
==6361== 24 bytes in 3 blocks are definitely lost in loss record 94 of 404
==6361== at 0x4005525: malloc (vg_replace_malloc.c:149)
==6361== by 0x3C0CF67: XtMalloc (in /usr/lib/libXt.so.6.0.0)
==6361== by 0x84AB96A: XtCompositeChildren (lwlib-utils.c:155)
==6361== by 0x846BEEF: x_tab_control_redisplay (glyphs-x.c:2785)
==6361== by 0x82DB826: redisplay_widget (glyphs-widget.c:480)
==6361== by 0x82B9544: redisplay_subwindow (glyphs.c:4704)
==6361== by 0x83B10EC: redisplay_output_subwindow (redisplay-output.c:1337)
==6361== by 0x8483A9F: x_output_display_block (redisplay-x.c:699)
==6361== by 0x83AEF35: redisplay_output_display_block
(redisplay-output.c:1246)
==6361== by 0x83B3646: output_display_line (redisplay-output.c:893)
==6361== by 0x82F6396: output_gutter (gutter.c:447)
==6361== by 0x82F6930: update_frame_gutters (gutter.c:644)
==6361== by 0x83ADB32: redisplay_frame (redisplay.c:6936)
==6361== by 0x83AE192: redisplay_device (redisplay.c:7026)
==6361== by 0x83AE627: redisplay_no_pre_idle_hook (redisplay.c:7101)
==6361== by 0x82181AA: Fnext_event (event-stream.c:2288)
==6361== by 0x81A07FF: Fcommand_loop_1 (cmdloop.c:599)
==6361== by 0x81A0963: command_loop_1 (cmdloop.c:505)
==6361== by 0x81FA001: condition_case_1 (eval.c:1946)
==6361== by 0x81A0B45: command_loop_2 (cmdloop.c:262)
==6361==
==6361==
==6361== 30 bytes in 1 blocks are possibly lost in loss record 109 of 404
==6361== at 0x4005525: malloc (vg_replace_malloc.c:149)
==6361== by 0x8B8D4A: (within /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8B5D5A: (within /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8B5D88: FcNameUnparse (in /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x848C3D3: Ffc_name_unparse (font-mgr.c:262)
==6361== by 0x81FF872: Ffuncall (eval.c:3928)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361==
==6361==
==6361== 4,808 (64 direct, 4,744 indirect) bytes in 2 blocks are
definitely lost in loss record 194 of 404
==6361== at 0x4004864: calloc (vg_replace_malloc.c:279)
==6361== by 0x816E228: xmalloc_and_zero (alloc.c:402)
==6361== by 0x822039D: pdump_load_finish (dumper.c:2264)
==6361== by 0x8220A44: pdump_load (dumper.c:2749)
==6361== by 0x81F1CB3: xemacs_21_5_b28_i686_pc_linux (emacs.c:1385)
==6361== by 0x81F2056: main (emacs.c:3112)
==6361==
==6361==
==6361== 112 (8 direct, 104 indirect) bytes in 1 blocks are definitely
lost in loss record 217 of 404
==6361== at 0x4005622: realloc (vg_replace_malloc.c:306)
==6361== by 0x6F8B83: (within /usr/lib/libX11.so.6.2.0)
==6361== by 0x6F971B: (within /usr/lib/libX11.so.6.2.0)
==6361== by 0x6FB677: _XlcCreateLC (in /usr/lib/libX11.so.6.2.0)
==6361== by 0x719AFA: _XlcDefaultLoader (in /usr/lib/libX11.so.6.2.0)
==6361== by 0x701FD2: _XOpenLC (in /usr/lib/libX11.so.6.2.0)
==6361== by 0x702112: _XlcCurrentLC (in /usr/lib/libX11.so.6.2.0)
==6361== by 0x7023D6: XSupportsLocale (in /usr/lib/libX11.so.6.2.0)
==6361== by 0x8489C4A: init_x_locale (intl-x.c:43)
==6361== by 0x830681E: Fset_current_locale (intl.c:85)
==6361== by 0x81FF872: Ffuncall (eval.c:3928)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x8189F00: Fbyte_code (bytecode.c:2620)
==6361== by 0x81FE0F8: Feval (eval.c:3676)
==6361== by 0x81F7CAF: internal_catch (eval.c:1552)
==6361== by 0x818337A: execute_rare_opcode (bytecode.c:1419)
==6361== by 0x8184EA7: execute_optimized_program (bytecode.c:754)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361==
==6361==
==6361== 214 bytes in 9 blocks are definitely lost in loss record 259 of 404
==6361== at 0x4005525: malloc (vg_replace_malloc.c:149)
==6361== by 0x8B9757: FcStrCopy (in /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8BCE16: (within /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x87E261: (within /lib/libexpat.so.1.5.2)
==6361== by 0x87EEDC: (within /lib/libexpat.so.1.5.2)
==6361== by 0x87FF93: (within /lib/libexpat.so.1.5.2)
==6361== by 0x880E64: (within /lib/libexpat.so.1.5.2)
==6361== by 0x87857A: XML_ParseBuffer (in /lib/libexpat.so.1.5.2)
==6361== by 0x8BBF9B: FcConfigParseAndLoad (in
/usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8BC2A2: FcConfigParseAndLoad (in
/usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8BC717: (within /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x87E261: (within /lib/libexpat.so.1.5.2)
==6361== by 0x87EEDC: (within /lib/libexpat.so.1.5.2)
==6361== by 0x87FF93: (within /lib/libexpat.so.1.5.2)
==6361== by 0x880E64: (within /lib/libexpat.so.1.5.2)
==6361== by 0x87857A: XML_ParseBuffer (in /lib/libexpat.so.1.5.2)
==6361== by 0x8BBF9B: FcConfigParseAndLoad (in
/usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8B1225: FcInitLoadConfig (in /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8B134B: FcInitLoadConfigAndFonts (in
/usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8B144B: FcInit (in /usr/lib/libfontconfig.so.1.2.0)
==6361==
==6361==
==6361== 216 bytes in 1 blocks are definitely lost in loss record 261 of 404
==6361== at 0x4005525: malloc (vg_replace_malloc.c:149)
==6361== by 0x703185: _XimOpenIM (in /usr/lib/libX11.so.6.2.0)
==6361== by 0x715DBF: _XimRegisterIMInstantiateCallback (in
/usr/lib/libX11.so.6.2.0)
==6361== by 0x6F2FB7: XRegisterIMInstantiateCallback (in
/usr/lib/libX11.so.6.2.0)
==6361== by 0x8224A6C: XIM_init_device (input-method-xlib.c:206)
==6361== by 0x8457731: x_init_device (device-x.c:872)
==6361== by 0x81C91D3: Fmake_device (device.c:667)
==6361== by 0x81FF8C3: Ffuncall (eval.c:3928)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FE3B8: Feval (eval.c:3737)
==6361== by 0x81FA001: condition_case_1 (eval.c:1946)
==6361== by 0x8201DFE: condition_case_3 (eval.c:2028)
==6361== by 0x81833C2: execute_rare_opcode (bytecode.c:1438)
==6361==
==6361==
==6361== 425 bytes in 14 blocks are definitely lost in loss record 283 of 404
==6361== at 0x4005525: malloc (vg_replace_malloc.c:149)
==6361== by 0x8B8D4A: (within /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8B5D5A: (within /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8B5D88: FcNameUnparse (in /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x848C3D3: Ffc_name_unparse (font-mgr.c:262)
==6361== by 0x81FF872: Ffuncall (eval.c:3928)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361==
==6361==
==6361== 864 bytes in 24 blocks are definitely lost in loss record 310 of 404
==6361== at 0x4005525: malloc (vg_replace_malloc.c:149)
==6361== by 0x7B2632: (within /usr/lib/libxcb.so.1.0.0)
==6361== by 0x7B138A: (within /usr/lib/libxcb.so.1.0.0)
==6361== by 0x7B2ED8: xcb_wait_for_reply (in /usr/lib/libxcb.so.1.0.0)
==6361== by 0x6ED15C: _XReply (in /usr/lib/libX11.so.6.2.0)
==6361== by 0x6C6F68: (within /usr/lib/libX11.so.6.2.0)
==6361== by 0x6C7A2C: XLoadQueryFont (in /usr/lib/libX11.so.6.2.0)
==6361== by 0x847648B: x_initialize_font_instance (objects-x.c:245)
==6361== by 0x836545F: Fmake_font_instance (objects.c:421)
==6361== by 0x8369026: font_instantiate (objects.c:946)
==6361== by 0x81FBCE7: call_with_suspended_errors (eval.c:5390)
==6361== by 0x83FB4EF: specifier_instance_from_inst_list (specifier.c:2883)
==6361== by 0x83FBB20: specifier_instance_1 (specifier.c:3055)
==6361== by 0x83FE539: specifier_matching_foo (specifier.c:3117)
==6361== by 0x83FE66A: Fspecifier_instance (specifier.c:3209)
==6361== by 0x81FF8F9: Ffuncall (eval.c:3928)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361==
==6361==
==6361== 1,332 (1,152 direct, 180 indirect) bytes in 9 blocks are
definitely lost in loss record 323 of 404
==6361== at 0x4005525: malloc (vg_replace_malloc.c:149)
==6361== by 0x8B7103: (within /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8B7A13: (within /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8B7B16: (within /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8BCC90: (within /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x87E261: (within /lib/libexpat.so.1.5.2)
==6361== by 0x87EEDC: (within /lib/libexpat.so.1.5.2)
==6361== by 0x87FF93: (within /lib/libexpat.so.1.5.2)
==6361== by 0x880E64: (within /lib/libexpat.so.1.5.2)
==6361== by 0x87857A: XML_ParseBuffer (in /lib/libexpat.so.1.5.2)
==6361== by 0x8BBF9B: FcConfigParseAndLoad (in
/usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8BC2A2: FcConfigParseAndLoad (in
/usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8BC717: (within /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x87E261: (within /lib/libexpat.so.1.5.2)
==6361== by 0x87EEDC: (within /lib/libexpat.so.1.5.2)
==6361== by 0x87FF93: (within /lib/libexpat.so.1.5.2)
==6361== by 0x880E64: (within /lib/libexpat.so.1.5.2)
==6361== by 0x87857A: XML_ParseBuffer (in /lib/libexpat.so.1.5.2)
==6361== by 0x8BBF9B: FcConfigParseAndLoad (in
/usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8B1225: FcInitLoadConfig (in /usr/lib/libfontconfig.so.1.2.0)
==6361==
==6361==
==6361== 3,280 bytes in 820 blocks are definitely lost in loss record 347 of 404
==6361== at 0x4005525: malloc (vg_replace_malloc.c:149)
==6361== by 0x816E2AD: xmalloc (alloc.c:390)
==6361== by 0x3BD268E: __gmpz_init (in /usr/lib/sse2/libgmp.so.3.4.2)
==6361== by 0x8170520: make_bignum_bg (alloc.c:1440)
==6361== by 0x81842A2: bytecode_arithop (bytecode.c:424)
==6361== by 0x8185211: execute_optimized_program (bytecode.c:1231)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x81FC873: funcall_compiled_function (eval.c:3517)
==6361== by 0x81FF6F7: Ffuncall (eval.c:3967)
==6361== by 0x8185CD9: execute_optimized_program (bytecode.c:862)
==6361== by 0x8189F00: Fbyte_code (bytecode.c:2620)
==6361== by 0x81FE0F8: Feval (eval.c:3676)
==6361== by 0x81FA001: condition_case_1 (eval.c:1946)
==6361== by 0x8201DFE: condition_case_3 (eval.c:2028)
==6361== by 0x81833C2: execute_rare_opcode (bytecode.c:1438)
==6361==
==6361==
==6361== 6,672 (2,304 direct, 4,368 indirect) bytes in 6 blocks are
definitely lost in loss record 355 of 404
==6361== at 0x4005622: realloc (vg_replace_malloc.c:306)
==6361== by 0x8B7043: (within /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8B7A13: (within /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8B7F0B: (within /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8B4760: FcFontRenderPrepare (in
/usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8B4947: FcFontSetMatch (in /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0x8B4B29: FcFontMatch (in /usr/lib/libfontconfig.so.1.2.0)
==6361== by 0xD5F46F: XftFontMatch (in /usr/lib/libXft.so.2.1.2)
==6361== by 0xD5F6E4: XftFontOpenName (in /usr/lib/libXft.so.2.1.2)
==6361== by 0x84AC081: xft_open_font_by_name (lwlib-fonts.c:92)
==6361== by 0x84763BE: x_initialize_font_instance (objects-x.c:236)
==6361== by 0x836545F: Fmake_font_instance (objects.c:421)
==6361== by 0x8369026: font_instantiate (objects.c:946)
==6361== by 0x81F4808: va_call_trapping_problems_1 (eval.c:5320)
==6361== by 0x81F7D33: call_trapping_problems_2 (eval.c:4968)
==6361== by 0x81F9E36: call_with_condition_handler (eval.c:2157)
==6361== by 0x81F9E93: call_trapping_problems_1 (eval.c:4974)
==6361== by 0x81F7CAF: internal_catch (eval.c:1552)
==6361== by 0x81FABC4: call_trapping_problems (eval.c:5247)
==6361== by 0x81FBB5D: call_with_suspended_errors (eval.c:5415)
==6361==
==6361== LEAK SUMMARY:
==6361== definitely lost: 8,564 bytes in 893 blocks.
==6361== indirectly lost: 9,396 bytes in 233 blocks.
==6361== possibly lost: 30 bytes in 1 blocks.
==6361== still reachable: 26,253,427 bytes in 17,865 blocks.
==6361== suppressed: 0 bytes in 0 blocks.
==6361== Reachable blocks (those to which a pointer was found) are not shown.
==6361== To see them, rerun with: --leak-check=full --show-reachable=yes
--
Jerry James
http://loganjerry.googlepages.com/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:27 a.m.
Jerry James writes:
I ran the latest Mercurial XEmacs under valgrind for awhile tonight,
just because I really enjoy using such a slow editor. :-) When I
exited, the leak check reported some lost blocks; i.e., memory that
was malloced but not freed. The leaked memory looks to be mostly Lisp
objects. Does this imply a garbage collector leak? Here are the
relevant entries.
Well, most of it looks to be in Xft. Why am I not surprised.
Some of the stuff in Xft is supposed to be refcounted, but what you do
and don't have to manage explicitly is nowhere documented.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:52 p.m.
On Jan 31, 2008 12:27 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Well, most of it looks to be in Xft. Why am I not surprised.
Some of the stuff in Xft is supposed to be refcounted, but what you do
and don't have to manage explicitly is nowhere documented.
That doesn't account for everything, though. Also, I traced through
the code associated with the biggest leak, of values returned from
XftFontOpenName. In fact, I did this awhile ago and found two places
in the code where XftFontClose should have been called but wasn't. I
fixed those. The finalize methods on the font objects do call
XftFontClose, and I've looked through the Xft code and verified that
it calls free() on the memory allocated by the stacktrace shown above.
So I set xft-debug-level to 3, which should make it print finalize
messages. I got none. So why isn't finalize being called on those
font objects? This is consistent with the other backtraces I have
analyzed, where the associated finalize method should free the memory
(that's the case for the bignum-related traces, for example).
Are we taking shortcuts when XEmacs quits that would lead to pointers
to Lisp objects being lost without those objects being garbage
collected? If so, what do you think of a Lisp-visible function that
calls VALGRIND_DO_LEAK_CHECK so we can see if anything has leaked
while XEmacs is still running?
--
Jerry James
http://loganjerry.googlepages.com/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:13 p.m.
Jerry James writes:
Are we taking shortcuts when XEmacs quits that would lead to
pointers
to Lisp objects being lost without those objects being garbage
collected?
I don't have an opinion, bang on Marcus's door. Which GC are you
using? If it's Marcus's (I hope so, pretty clearly that's the Way of
the Future), then internal GC problems of various shapes and sizes are
quite credible (no offense to Marcus, just that AIUI inventing a
reliable GC is an incredibly hard problem, and I don't understand his
paper well enough -- ie, not at all -- to see a correctness proof :-).
However, I have a reason for singling out Xft. First, like most X11
code, the documentation about this stuff sucks (you're supposed to
know The X11 Way by heart), and there are few checks to make sure that
the callers know what they're doing. Second, I don't trust any of the
people who did a lot of work on Xft (me, Aidan, Eric Knauel) to get
GCPROs right, and we are seeing a lot more crashes that could be wild
pointers (Thomas Mittelstaed's travails on AIX for example) recently.
GCPRO problems could easily go back to 2002 and Ben's Great Mule
Merge, as only recently have lots of users been switching to 21.5 for
decent Unicode support. I do trust ben to get it 99.9% right, but I
bet he touched 2000 GCPROs in that process. I'd be surprised if he
left less than 1 GCPRO bug behind :-) (and I don't mean "too much"
GCPRO, either).
If so, what do you think of a Lisp-visible function that
calls VALGRIND_DO_LEAK_CHECK so we can see if anything has leaked
while XEmacs is still running?
#ifdef DEBUG_XEMACS it and it has my vote, no matter how cheesy. :-)
Better yet, make it non-cheesy and always available. If valgrind
still requires special compilation like it used to, add a 'valgrind
feature and appropriate checks.
Then how about a valgrind Make target that would do "make check" but
with valgrind watching?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:14 p.m.
On Jan 31, 2008 12:13 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
I don't have an opinion, bang on Marcus's door. Which GC are
you
using? If it's Marcus's (I hope so, pretty clearly that's the Way of
the Future), then internal GC problems of various shapes and sizes are
quite credible (no offense to Marcus, just that AIUI inventing a
reliable GC is an incredibly hard problem, and I don't understand his
paper well enough -- ie, not at all -- to see a correctness proof :-).
I'm using Marcus's GC. I should read his paper....
However, I have a reason for singling out Xft. First, like most X11
code, the documentation about this stuff sucks (you're supposed to
know The X11 Way by heart), and there are few checks to make sure that
the callers know what they're doing. Second, I don't trust any of the
people who did a lot of work on Xft (me, Aidan, Eric Knauel) to get
GCPROs right, and we are seeing a lot more crashes that could be wild
pointers (Thomas Mittelstaed's travails on AIX for example) recently.
GCPRO problems could easily go back to 2002 and Ben's Great Mule
Merge, as only recently have lots of users been switching to 21.5 for
decent Unicode support. I do trust ben to get it 99.9% right, but I
bet he touched 2000 GCPROs in that process. I'd be surprised if he
left less than 1 GCPRO bug behind :-) (and I don't mean "too much"
GCPRO, either).
:-) Too little GCPRO should get flagged by valgrind as access to
unallocated memory if the garbage collector yanks the object away when
we're still using it. I haven't seen one of those yet, although I
can't stand to work on a valgrinded XEmacs for more than about 30
minutes at a time, and I'm no longer running the Great Gnus Bug
Detector.:-(
#ifdef DEBUG_XEMACS it and it has my vote, no matter how cheesy. :-)
Better yet, make it non-cheesy and always available. If valgrind
still requires special compilation like it used to, add a 'valgrind
feature and appropriate checks.
Then how about a valgrind Make target that would do "make check" but
with valgrind watching?
Good ideas. I'll try to get to all that in the next week.
--
Jerry James
http://loganjerry.googlepages.com/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:23 a.m.
>>>>"JJ" == Jerry James <james(a)xemacs.org>
writes:
JJ> Are we taking shortcuts when XEmacs quits that would lead to
JJ> pointers to Lisp objects being lost without those objects being
JJ> garbage collected?
Currently the garbage collector does not run the finalizers when
XEmacs exits. This is bad, we should definitely fix this. I see if I
can come up with a patch in the next couple of days.
--
Marcus
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:08 a.m.
Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> writes:
>>>>>"JJ" == Jerry James
<james(a)xemacs.org> writes:
JJ> Are we taking shortcuts when XEmacs quits that would lead to
JJ> pointers to Lisp objects being lost without those objects being
JJ> garbage collected?
Currently the garbage collector does not run the finalizers when
XEmacs exits. This is bad, we should definitely fix this. I see if I
can come up with a patch in the next couple of days.
This kind of stuff can't work in general. (Even though the assumption
that it can be done is common, and was made in the early Java versions.)
For the gory details, see:
http://www.hpl.hp.com/techreports/2002/HPL-2002-335.ps
--
Cheers =8-} M.
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6 a.m.
Michael Sperber writes:
Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> writes:
> Currently the garbage collector does not run the finalizers
when
> XEmacs exits. This is bad, we should definitely fix this. I see if I
> can come up with a patch in the next couple of days.
This kind of stuff can't work in general. (Even though the assumption
that it can be done is common, and was made in the early Java versions.)
For the gory details, see:
http://www.hpl.hp.com/techreports/2002/HPL-2002-335.ps
Note that (AFAICT IANAL) the "gory details" do point out that if it's
simply a matter of releasing system resources, these problems don't
arise. I don't know whether it's feasible to make that distinction in
Lisp, though.
The claim is also made that "in well-written code" only one line in
10000 should refer to finalization. Is that true of XEmacs?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:01 a.m.
>>>>"SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> The claim is also made that "in
well-written code" only one line in
SJT> 10000 should refer to finalization. Is that true of XEmacs?
Yeah, pretty much: I was able to nuke many finalizers by transforming
separately allocated data structures to Lisp objects. Some of the
remaining finalizers are also likely to go away, as soon as I (or
someone else) find the time to lift the remaining, separately allocated
objects to Lisp objects. Then, the garbage collector takes care of all
resources; finalizers that only free additional memory are no longer
needed.
--
Marcus
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:45 a.m.
Marcus Crestani writes:
Yeah, pretty much: I was able to nuke many finalizers by
transforming
separately allocated data structures to Lisp objects. Some of the
remaining finalizers are also likely to go away, as soon as I (or
someone else) find the time to lift the remaining, separately allocated
objects to Lisp objects.
Is this "lifting" process documented somewhere?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
12:14 p.m.
>>>>"SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> Marcus Crestani writes:
> Yeah, pretty much: I was able to nuke many finalizers by
transforming
> separately allocated data structures to Lisp objects. Some of the
> remaining finalizers are also likely to go away, as soon as I (or
> someone else) find the time to lift the remaining, separately allocated
> objects to Lisp objects.
SJT> Is this "lifting" process documented somewhere?
I wrote about it when I first introduced the incremental garbage
collector (back in November 2005). Unfortunately, the archive for
xemacs-patches does not go back that far, so here is the interesting
excerpt from my old post:
/---
Unfortunately, the current Lisp object layout leads to holes in the
write barrier: Not all data structures that contain pointers to Lisp
objects are allocated on the Lisp heap. Some Lisp objects do not carry
all their information in the object itself. External parts are kept in
separately allocated memory blocks that are not managed by the new Lisp
allocator. Examples for these objects are hash tables and dynamic
arrays, two objects that can dynamically grow and shrink. The separate
memory blocks are not guaranteed to reside on page boundaries, and thus
cannot be watched by the write barrier.
Moreover, the separate parts can contain live pointers to other Lisp
objects. These pointers are not covered by the write barrier and
modifications by the client during garbage collection do escape. In
this case, the client changes the connectivity of the reachability
graph behind the collector's back, which eventually leads to erroneous
collection of live objects. To solve this problem, I transformed the
separately allocated parts to fully qualified Lisp objects that are
managed by the allocator and thus are covered by the write barrier.
This also removes a lot of special allocation and removal code for the
out-sourced parts. Generally, allocating all data structures that
contain pointers to Lisp objects on one heap makes the whole memory
layout more consistent.
A large part of the patch converts these data structures to Lisp
objects. The conversion of an additionally allocated data structure to
an Lisp objects includes:
- Add new object type to enum lrecord_type in lrecord.h.
- Add lrecord_header to the object's struct.
- Add DECLARE_RECORD()/XFOO/etc. below the struct definition.
- Add lrecord definition.
- Change allocation with malloc to allocation with new allocator.
- Add object to syms_of_*().
- Change memory description of parent object.
- Modify finalizer, free, or delete functions.
\---
The initial motivation for this is the write barrier and the consistent
format for all objects that may contain Lisp pointers. That we can get
rid of finalizers this way follows naturally.
--
Marcus
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:37 a.m.
New subject: [AC21.5] Document "lifting to Lisp" [was: GC leak?]
APPROVE COMMIT 21.5
Maybe it's not the best place for it, but it sure beats offline
archives.
diff -r 42711a251efd man/ChangeLog
--- a/man/ChangeLog Fri Feb 15 13:11:56 2008 +0100
+++ b/man/ChangeLog Wed Feb 27 14:33:25 2008 +0900
＠＠ -0,0 +1,10 ＠＠ 2007-12-17 Aidan Kehoe <kehoea＠parhasa
+2008-02-27 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ * internals/internals.texi (Discussion -- KKCC):
+ (Discussion -- Incremental Collector):
+ New nodes.
+ (Top):
+ (Discussion -- Garbage Collection):
+ (Discussion -- Pure Space):
+ Adjust pointers and menus for new nodes.
+
+ (lrecords): Remark that lcrecords are obsolete.
+
diff -r 42711a251efd man/internals/internals.texi
--- a/man/internals/internals.texi Fri Feb 15 13:11:56 2008 +0100
+++ b/man/internals/internals.texi Wed Feb 27 14:33:25 2008 +0900
＠＠ -740,6 +740,8 ＠＠ Future Work Discussion
Discussion -- Garbage Collection
+* Discussion -- KKCC::
+* Discussion -- Incremental Collector::
* Discussion -- Pure Space::
* Discussion -- Hashtable-Based Marking and Cleanup::
* Discussion -- The Anti-Cons::
＠＠ -8551,6 +8553,9 ＠＠ more defensive but less efficient and is
[see ＠file{lrecord.h}]
+＠strong{This node needs updating for the ``new garbage collection
+algorithms'' (KKCC) and the ``incremental'' collector.}
+
All lrecords have at the beginning of their structure a ＠code{struct
lrecord_header}. This just contains a type number and some flags,
including the mark bit. All builtin type numbers are defined as
＠＠ -8570,6 +8575,9 ＠＠ field used to distinguish one lcrecord f
field used to distinguish one lcrecord from another. (This field is used
only for debugging and could be removed, but the space gain is not
significant.)
+
+＠strong{lcrecords are now obsolete when using the write-barrier-based
+collector.}
Simple lrecords are created using ＠code{ALLOCATE_FIXED_TYPE()}, just
like for other frob blocks. The only change is that the implementation
＠＠ -28419,12 +28427,82 ＠＠ into the normal Future Work section.
＠cindex garbage collection, discussion
＠menu
+* Discussion -- KKCC::
+* Discussion -- Incremental Collector::
* Discussion -- Pure Space::
* Discussion -- Hashtable-Based Marking and Cleanup::
* Discussion -- The Anti-Cons::
＠end menu
-＠node Discussion -- Pure Space, Discussion -- Hashtable-Based Marking and Cleanup,
Discussion -- Garbage Collection, Discussion -- Garbage Collection
+＠node Discussion -- KKCC, Discussion -- Incremental Collector, Discussion -- Garbage
Collection, Discussion -- Garbage Collection
+＠subsection Discussion -- KKCC
+＠cindex discussion, KKCC
+＠cindex KKCC, discussion
+
+KKCC is the tag used for the ``new garbage collector algorithms,'' which
+are a refactoring of the garbage collector to make trying new collectors
+simpler.
+
+＠node Discussion -- Incremental Collector, Discussion -- Pure Space, Discussion -- KKCC,
Discussion -- Garbage Collection
+＠subsection Discussion -- Incremental Collector
+＠cindex discussion, Incremental Collector
+＠cindex Incremental Collector, discussion
+
+The incremental collector is designed to allow better ``realtime''
+performance by not requiring a full mark and sweep pass. This also
+allows removal of most finalizers, as described in
+＠samp{<vpd8x1fomdx.fsf＠(a)informatik.uni-tuebingen.de>} by Marcus Crestani
+on xemacs-beta:
+
+I was able to nuke many finalizers by transforming
+separately allocated data structures to Lisp objects. Some of the
+remaining finalizers are also likely to go away, as soon as I (or
+someone else) find the time to ``lift'' the remaining, separately allocated
+objects to Lisp objects.
+
+Unfortunately, the current Lisp object layout leads to holes in the
+write barrier: Not all data structures that contain pointers to Lisp
+objects are allocated on the Lisp heap. Some Lisp objects do not carry
+all their information in the object itself. External parts are kept in
+separately allocated memory blocks that are not managed by the new Lisp
+allocator. Examples for these objects are hash tables and dynamic
+arrays, two objects that can dynamically grow and shrink. The separate
+memory blocks are not guaranteed to reside on page boundaries, and thus
+cannot be watched by the write barrier.
+
+Moreover, the separate parts can contain live pointers to other Lisp
+objects. These pointers are not covered by the write barrier and
+modifications by the client during garbage collection do escape. In
+this case, the client changes the connectivity of the reachability
+graph behind the collector's back, which eventually leads to erroneous
+collection of live objects. To solve this problem, I transformed the
+separately allocated parts to fully qualified Lisp objects that are
+managed by the allocator and thus are covered by the write barrier.
+This also removes a lot of special allocation and removal code for the
+out-sourced parts. Generally, allocating all data structures that
+contain pointers to Lisp objects on one heap makes the whole memory
+layout more consistent.
+
+A large part of the patch converts these data structures to Lisp
+objects. The conversion of an additionally allocated data structure to
+an Lisp objects includes:
+＠itemize
+＠item Add new object type to ＠samp{enum lrecord_type} in ＠file{lrecord.h}.
+＠item Add ＠samp{lrecord_header} to the object's struct.
+＠item Add ＠samp{DECLARE_RECORD()}/＠samp{XFOO}/etc. below the struct definition.
+＠item Add lrecord definition.
+＠item Change allocation with malloc to allocation with new allocator.
+＠item Add object to ＠samp{syms_of_*()}.
+＠item Change memory description of parent object.
+＠item Modify finalizer, free, or delete functions.
+＠end itemize
+
+The initial motivation for this is the write barrier and the consistent
+format for all objects that may contain Lisp pointers. That we can get
+rid of finalizers this way follows naturally.
+
+
+＠node Discussion -- Pure Space, Discussion -- Hashtable-Based Marking and Cleanup,
Discussion -- Incremental Collector, Discussion -- Garbage Collection
＠subsection Discussion -- Pure Space
＠cindex discussion, pure space
＠cindex pure space, discussion
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5903
days inactive
5930
days old
11 comments
4 participants
participants (4)
-
Jerry James -
Marcus Crestani -
Michael Sperber -
Stephen J. Turnbull