- Gambit-list - mailman.iro.umontreal.ca

Re: [gambit-list] Documentation
by Mikael 22 Jui '13

22 Jui '13

Just provide a very very clear format and structure for how this documentation should be committed into and represented in the repo, and I'm sure there's people who are happy to contribute. What in the documentation can be cleaned up? 2013/6/20 Marc Feeley <feeley(a)iro.umontreal.ca> > > On Jun 20, 2013, at 10:09 AM, Guillaume Cartier <gcartier(a)jazzscheme.org> > wrote: > > > There is also the 6.4 Undocumented extensions section in the Gambit > manual that is there for this purpose, correct me if I'm wrong Marc. > > In principle that section if for documenting the existence of procedures > that don't have documentation. I see that the first few are documented and > should be moved elsewhere! The documentation should be cleaned up. Are > there people out there with some free time and a generous nature? > > Marc > > _______________________________________________ > Gambit-list mailing list > Gambit-list(a)iro.umontreal.ca > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list >

3 2

(##resolve-referencing-objects obj) => list of the objects that reference obj implementation, feedback welcome.
by Mikael 22 Jui '13

22 Jui '13

Ok, looks like ##resolve-referencing-objects is in place now! > (define a "Hello world") > (##resolve-referencing-objects a) (#<absent> #<absent> #<absent>) > (list a) ("Hello world") > (##resolve-referencing-objects a) (#<absent> #<absent> #<absent> ("Hello world")) > (vector a) #("Hello world") > (##resolve-referencing-objects a) (#<absent> #<absent> #<absent> #("Hello world") ("Hello world")) > 0 1 2 0 > 1 > 2 > (##gc) > (##resolve-referencing-objects a) (#<absent> #<absent> #<absent>) Implementation: To _kernel.scm row 4388 and on are added: ;;;---------------------------------------------------------------------------- ;;; Resolver of referencing objects ;;; Works for memory-allocated objects only, for details see the conditions for ;;; the validate_old_obj call in mem.c . ; For this procedure to work, up to the point where the explicitly induced GC is made, ; there must be no other GC. ; ; (##resolve-referencing-objects obj) => list of the objects that reference obj (define (##resolve-referencing-objects obj) (##declare (not interrupts-enabled)) ; Set the object to scan for (##c-code #<<end-of-code // Note that this variable is declared even if the referencing objects resolver // is not enabled. resolve_objects_referencing = ___ARG1; end-of-code obj) ; Trig garbage collection as to perform the scan (##gc) ; Reset the object to scan for setting (##c-code #<<end-of-code resolve_objects_referencing = -1; end-of-code ) ; Simplistic way of indicating to user whether this procedure is implemented. (and (##c-code #<<end-of-code #ifdef ___DEBUG ___RESULT = ___TRU; #else ___RESULT = ___FAL; #endif end-of-code ) ; Download the resolved objects and return (let loop ((r '())) (let ((object (##c-code "___RESULT = get_next_resolved_referencing_object();"))) (if object (loop (cons object r)) r))))) To mem.h row 69 and on are added: extern ___SCMOBJ resolve_objects_referencing; extern ___SCMOBJ get_next_resolved_referencing_object ___PVOID; To mem.h are added starting at the following rows: 30: /* * Defining the symbol ENABLE_REFERENCING_OBJECTS_RESOLVER will enable * the GC to resolve the references to a specified object, see * ##resolve-referencing-objects of _kernel.scm for more info. */ #define ENABLE_REFERENCING_OBJECTS_RESOLVER 423: /* Object to look up all references to */ ___WORD resolve_objects_referencing = -1; typedef struct resolved_referencing_object_struct { ___SCMOBJ object; struct resolved_referencing_object_struct* next; } resolved_referencing_object; ___HIDDEN resolved_referencing_object* resolved_referencing_objects = NULL; void add_resolved_referencing_object(___SCMOBJ object) { resolved_referencing_object* r = (resolved_referencing_object*) malloc(sizeof(resolved_referencing_object)); r->object = object; r->next = resolved_referencing_objects; resolved_referencing_objects = r; } // Get next object resolved as referencing resolve_objects_referencing . // Used by ##resolve-referencing-objects ___SCMOBJ get_next_resolved_referencing_object ___PVOID { if (resolved_referencing_objects == NULL) { return ___FAL; } else { resolved_referencing_object* r = resolved_referencing_objects; ___SCMOBJ object = r->object; resolved_referencing_objects = r->next; free(r); return object; } } 2184 (replacing the previous ifdef-endif validate_old_obj block): #if defined(ENABLE_CONSISTENCY_CHECKS) || defined(ENABLE_REFERENCING_OBJECTS_RESOLVER) #ifdef ENABLE_REFERENCING_OBJECTS_RESOLVER if (obj == resolve_objects_referencing) { // This typecasting of container_body to ___SCMOBJ was inspired by the corresponding code in explain_problem . if (reference_location == IN_OBJECT) { // Reference from other Scheme object's body ___WORD container; #if ___tPAIR != ___tSUBTYPED ___WORD head = container_body[-1]; int subtype = ___HD_SUBTYPE(head); if (subtype == ___sPAIR) container = ___TAG(container_body-___BODY_OFS,___tPAIR); else #endif container = ___TAG(container_body-___BODY_OFS,___tSUBTYPED); // ___printf("Found match to sought for object %lu : ",resolve_objects_referencing); // print_object(container,0,"",0); // ___printf("\n"); add_resolved_referencing_object(container); } else { // Reference from global variable etc. add_resolved_referencing_object(___ABSENT); } } #endif #ifdef ENABLE_CONSISTENCY_CHECKS if (___DEBUG_SETTINGS_LEVEL(___setup_params.debug_settings) >= 1) validate_old_obj (obj); #endif #endif and the #define ENABLE_CONSISTENCY_CHECKS :s that regard a block that define or set reference_location are replaced with #if defined(ENABLE_CONSISTENCY_CHECKS) || defined(ENABLE_REFERENCING_OBJECTS_RESOLVER) . Compilation of a new ./gsc/gsc (g++): cd lib g++ -Wno-unused -Wno-write-strings -g -fno-trapping-math -fno-strict-aliasing -fwrapv -fPIC -fno-common -mieee-fp -I"../include" -c -o "mem.o" -I. -DHAVE_CONFIG_H -D___GAMBCDIR="\"/usr/local/Gambit-C\"" -D___SYS_TYPE_CPU="\"i686\"" -D___SYS_TYPE_VENDOR="\"pc\"" -D___SYS_TYPE_OS="\"linux-gnu\"" -D___CONFIGURE_COMMAND="\"./configure '--enable-cplusplus' '--enable-single-host' '--enable-debug'"\" -D___OBJ_EXTENSION="\".o\"" -D___EXE_EXTENSION="\"\"" -D___BAT_EXTENSION="\"\"" -D___PRIMAL mem.c -D___LIBRARY gsc -:~~bin=../bin,~~lib=../lib,~~include=../include -c _kernel.scm gsc -:~~bin=../bin,~~lib=../lib,~~include=../include -f -link -flat -o _gambc.c _kernel.c _system.c _num.c _std.c _eval.c _io.c _nonstd.c _thread.c _repl.c g++ -Wno-unused -Wno-write-strings -g -fno-trapping-math -fno-strict-aliasing -fwrapv -fPIC -fno-common -mieee-fp -I"../include" -c -o "_kernel.o" -I. -DHAVE_CONFIG_H -D___GAMBCDIR="\"/usr/local/Gambit-C\"" -D___SYS_TYPE_CPU="\"i686\"" -D___SYS_TYPE_VENDOR="\"pc\"" -D___SYS_TYPE_OS="\"linux-gnu\"" -D___CONFIGURE_COMMAND="\"./configure '--enable-cplusplus' '--enable-single-host' '--enable-debug'"\" -D___OBJ_EXTENSION="\".o\"" -D___EXE_EXTENSION="\"\"" -D___BAT_EXTENSION="\"\"" -D___PRIMAL _kernel.c -D___LIBRARY cd .. make Space for improvement or things to note are: * ##resolve-referencing-objects is always compiled, but returns #f if Gambit is not compiled with --enable-debug . Possibly some neater or otherwise better degradation of the procedure could be devised for when Gambit is not compiled in debug mode? * When compiled with --debug, on the iteration over each memory-allocated object, two checks are always done, namely the two highlighted above. These could easily be united to one collective check, by making a global boolean variable sth like perform_individual_object_checks that's set to (resolve_objects_referencing != -1) || (___DEBUG_SETTINGS_LEVEL(___setup_params.debug_settings) >= 1) on ___garbage_collect . Those two checks would then be surrounded by if (perform_individual_object_checks) { .. } . This would save some clock cycles in the ordinary use case, but add ~5 lines of complexity to mem.c . * Note that object references that are from objects other than Gambit standard objects, are represented as an absent special object. * I did not implement this in validate_old_obj as ##resolve-referencing-objects is quite common to use and validate_old_obj in contrast looks like a very expensive, special-purpose routine. Feedback? Mikael 2013/6/18 Marc Feeley <feeley(a)iro.umontreal.ca> > Also, your code would be useful to others, so please do a pull request > when you are done. > > Marc > > On Jun 18, 2013, at 12:00 PM, Mikael <mikael.rcv(a)gmail.com> wrote: > > > Ah, yey, your code in explain_problem already provided an example of how > to do this! > > > > Will write here soon how to do this lookup of referencing objects soon. > > > >

2 6

Could anything inhibit ordinary course of the GC collecting?
by Mikael 20 Jui '13

20 Jui '13

Dear Marc, Is there anything that could inhibit the GC's due course of collecting objects? Like.. a misbehaving will or FFI object or something of the sort. I'm trying figure out what the problem I'm seeing is based on - basically, threads, wills, ports and some other objects remain on the heap. Currently it could be anything that causes it. Very well, working with reducing it.. Thanks, Mikael

1 0

Progress with the memory leak hunting, the root reference is a 'thread-call-result mutex referencing a continuation starting w ##thread-call . What this means?
by Mikael 20 Jui '13

20 Jui '13

Dear Marc, Soo I've hunted this memory leak down a bit now and I'm starting to feel I got somewhere: So basically I noted that my heap was filling up with a vector object that I use for IO. Now analyzed what references it using ##resolve-referencing-objects . This memory leak seems to happen for something-like-in-the-range every 10:th incoming TCP connection. It's handled by Sack, and then as we see left on the heap are some structures regarding its I/O. This is a bit funny as I have the impression that Sack can run without producing any memory leaks too. Here's the tracing of the root for such a vector: A stack frame is referencing it, which is of a procedure that I provide, whose invocation ended long ago. That stack frame in turn is referenced by the procedure that created the vector. And that stack frame in turn is referenced by ##read-u8 (!) And that stack frame in turn is referenced by ##byte-rbuf-fill (!) And that stack frame in turn is referenced by ##wait-for-io! (!) And that stack frame in turn is referenced by ##thread-interrupt! (!) And that stack frame in turn is referenced by ##thread-call (!) And that stack frame in turn is referenced by a continuation object. The continuation object's denv is #(#((#<procedure #N current-directory> . "/home/USER/") () ()) #(0) 0 0 (#<procedure #N current-exception-handler> . #<procedure #N primordial-exception-handler>) (#<procedure #N current-input-port> . #<input-output-port #N dummy>) (#<procedure #N current-output-port> . #<input-output-port #N dummy>) (#f . #f)) That continuation object in turn is referenced by * A mutex with the mutex-name 'thread-call-result , mutex-state #<thread #1 primordial> , mutex-specific set to the continuation itself. * This vector #(3 2 #<continuation #N> #!unbound) - I think that's a product of the evaluator * (#<continuation #N>) * (#<continuation #N> . #t) The mutex is in turn referenced by another three mutexes, each being a 'thread-call-result mutex with another continuation as its specific. If there's anything more that's relevant for me to check here, feel free to let me know. Do you see any plausible reason for the leak? Best regards, Mikael

5 12

Re: [gambit-list] How introspect frame objects
by Mikael 20 Jui '13

20 Jui '13

Aha got it: For a frame object, (##frame o) => #t (##subprocedure-parent-name (##frame-ret o)) => the name of the procedure that the frame regards e.g. ##read-u8 (##frame-ref o N) where N = 0 .. (##frame-fs o) - 1 => the frame's bound objects, (##frame-slot-live? o N) checks the respective slot for aliveness. 2013/6/20 Mikael <mikael.rcv(a)gmail.com> > Dear Marc, > > In memory leak hunting I've gotten to a place where there's two stack > frame objects that keep the leaking pointer. > > How can I introspect #<frame #[number]> objects to understand where in the > sourcecode they come from in terms of location, code content and variable > content? > > Thanks, > Mikael > > >

2 1

(##resolve-referencing-objects obj), some more note, and question on how make more stable, seems like it eventually pick up some "prohibited" reference??
by Mikael 20 Jui '13

20 Jui '13

*(1)* I've implemented a routine to dig out the GC roots for a given object, |dig-out-gc-roots-graph| . For it to work out, |##resolve-referencing-objects| needed to return weak references. Not clear about exactly why, anyhow so the last rows in it in _kernel.scm need to be: ; Download the resolved objects and return. ; We keep the references weak as to keep the interference induced by this mechanism ; on recurring resolves minimal. ; ; test: eq? as we want uniqueness to be per unique object reference. (let ((r (*make-table* weak-keys: #t test: eq?))) (let loop () (let ((object (##c-code "___RESULT = get_next_resolved_referencing_object();"))) (if object (begin (table-set! r object #t) (loop))))) r))) because of this. *(2)* ##resolve-referencing-objects does *not* traverse weak references, which is as it should. Why it does not though, I must admit that I'm not clear about, as it looks to me like that __garbage_collect should be including those too. *(3)* It happens that |dig-out-gc-roots-graph| / |##resolve-referencing-objects| makes the GC pass break, any clue why? >>> The GC has detected the following inconsistency >>> during call of mark_array on line 3250 of mem.c: >>> Memory map: >>> msection 0: 0x00cf4028 .. 0x00d74028 .. 0x00df4028 >>> msection 1: 0x019fc028 .. 0x01a7c028 .. 0x01afc028 >>> msection 2: 0x01afd028 .. 0x01b7d028 .. 0x01bfd028 >>> msection 3: 0x01bfe028 .. 0x01c7e028 .. 0x01cfe028 >>> msection 4: 0x030e1028 .. 0x03161028 .. 0x031e1028 >>> msection 5: 0x0422f028 .. 0x042af028 .. 0x0432f028 >>> msection 6: 0x04acc028 .. 0x04b4c028 .. 0x04bcc028 >>> msection 7: 0x0562b028 .. 0x056ab028 .. 0x0572b028 >>> msection 8: 0x064df028 .. 0x0655f028 .. 0x065df028 >>> msection 9: 0x070fa028 .. 0x0717a028 .. 0x071fa028 >>> msection 10: 0x077ba028 .. 0x0783a028 .. 0x078ba028 >>> msection 11: 0x07e45028 .. 0x07ec5028 .. 0x07f45028 >>> msection 12: 0x08805028 .. 0x08885028 .. 0x08905028 >>> msection 13: 0x0a06d028 .. 0x0a0ed028 .. 0x0a16d028 >>> msection 14: 0x0aa5c028 .. 0x0aadc028 .. 0x0ab5c028 >>> msection 15: 0x0ac22028 .. 0x0aca2028 .. 0x0ad22028 >>> msection 16: 0x0b3c5028 .. 0x0b445028 .. 0x0b4c5028 >>> msection 17: 0x0b9b6028 .. 0x0ba36028 .. 0x0bab6028 >>> msection 18: 0x0c0ab028 .. 0x0c12b028 .. 0x0c1ab028 >>> msection 19: 0x0c88e028 .. 0x0c90e028 .. 0x0c98e028 >>> msection 20: 0x0df7e028 .. 0x0dffe028 .. 0x0e07e028 >>> msection 21: 0x0ec0f028 .. 0x0ec8f028 .. 0x0ed0f028 >>> msection 22: 0x0ef35028 .. 0x0efb5028 .. 0x0f035028 >>> msection 23: 0x1c09a028 .. 0x1c11a028 .. 0x1c19a028 >>> msection 24: 0x1e1ac028 .. 0x1e22c028 .. 0x1e2ac028 >>> msection 25: 0x1e2ad028 .. 0x1e32d028 .. 0x1e3ad028 >>> msection 115: 0x23d07028 .. 0x23d87028 .. 0x23e07028 >>> msection 116: 0x23e08028 .. 0x23e88028 .. 0x23f08028 >>> msection 117: 0x23f09028 .. 0x23f89028 .. 0x24009028 >>> msection 118: 0x2400a028 .. 0x2408a028 .. 0x2410a028 >>> msection 119: 0x2410b028 .. 0x2418b028 .. 0x2420b028 >>> msection 120: 0x2420c028 .. 0x2428c028 .. 0x2430c028 >>> msection 121: 0x2430d028 .. 0x2438d028 .. 0x2440d028 >>> msection 122: 0x2440e028 .. 0x2448e028 .. 0x2450e028 >>> msection 123: 0x2450f028 .. 0x2458f028 .. 0x2460f028 >>> msection 124: 0x24610028 .. 0x24690028 .. 0x24710028 >>> msection 125: 0x24711028 .. 0x24791028 .. 0x24811028 >>> msection 126: 0x24812028 .. 0x24892028 .. 0x24912028 >>> msection 127: 0x24913028 .. 0x24993028 .. 0x24a13028 >>> msection 128: 0x24a14028 .. 0x24a94028 .. 0x24b14028 >>> msection 129: 0x24b15028 .. 0x24b95028 .. 0x24c15028 >>> msection 130: 0x24c16028 .. 0x24c96028 .. 0x24d16028 >>> msection 131: 0x24d17028 .. 0x24d97028 .. 0x24e17028 >>> msection 132: 0x24e18028 .. 0x24e98028 .. 0x24f18028 >>> msection 133: 0x24f19028 .. 0x24f99028 .. 0x25019028 >>> msection 134: 0x2501a028 .. 0x2509a028 .. 0x2511a028 >>> msection 135: 0x2511b028 .. 0x2519b028 .. 0x2521b028 >>> msection 136: 0x2521c028 .. 0x2529c028 .. 0x2531c028 >>> msection 137: 0x2531d028 .. 0x2539d028 .. 0x2541d028 >>> msection 138: 0x2541e028 .. 0x2549e028 .. 0x2551e028 >>> msection 139: 0x2551f028 .. 0x2559f028 .. 0x2561f028 >>> msection 140: 0x25620028 .. 0x256a0028 .. 0x25720028 >>> msection 141: 0x25721028 .. 0x257a1028 .. 0x25821028 >>> msection 142: 0x25822028 .. 0x258a2028 .. 0x25922028 >>> msection 143: 0x25923028 .. 0x259a3028 .. 0x25a23028 >>> msection 144: 0x25a24028 .. 0x25aa4028 .. 0x25b24028 >>> msection 145: 0x25b25028 .. 0x25ba5028 .. 0x25c25028 >>> msection 146: 0x25c26028 .. 0x25ca6028 .. 0x25d26028 >>> msection 147: 0x25d27028 .. 0x25da7028 .. 0x25e27028 >>> msection 148: 0x25e28028 .. 0x25ea8028 .. 0x25f28028 >>> msection 149: 0x25f29028 .. 0x25fa9028 .. 0x26029028 >>> msection 150: 0x2602a028 .. 0x260aa028 .. 0x2612a028 >>> msection 151: 0x2612b028 .. 0x261ab028 .. 0x2622b028 >>> msection 152: 0x2622c028 .. 0x262ac028 .. 0x2632c028 >>> msection 153: 0x2632d028 .. 0x263ad028 .. 0x2642d028 >>> msection 154: 0x2642e028 .. 0x264ae028 .. 0x2652e028 >>> msection 155: 0x2652f028 .. 0x265af028 .. 0x2662f028 >>> msection 156: 0x26630028 .. 0x266b0028 .. 0x26730028 >>> msection 157: 0x26731028 .. 0x267b1028 .. 0x26831028 >>> msection 158: 0x26832028 .. 0x268b2028 .. 0x26932028 >>> msection 159: 0x26933028 .. 0x269b3028 .. 0x26a33028 >>> msection 160: 0x26a34028 .. 0x26ab4028 .. 0x26b34028 >>> msection 161: 0x26b35028 .. 0x26bb5028 .. 0x26c35028 >>> msection 162: 0x26c36028 .. 0x26cb6028 .. 0x26d36028 >>> msection 163: 0x26d37028 .. 0x26db7028 .. 0x26e37028 >>> msection 164: 0x26e38028 .. 0x26eb8028 .. 0x26f38028 >>> msection 165: 0x26f39028 .. 0x26fb9028 .. 0x27039028 >>> msection 166: 0x2703a028 .. 0x270ba028 .. 0x2713a028 >>> msection 167: 0x2713b028 .. 0x271bb028 .. 0x2723b028 >>> msection 168: 0x2723c028 .. 0x272bc028 .. 0x2733c028 >>> msection 169: 0x2733d028 .. 0x273bd028 .. 0x2743d028 >>> msection 170: 0x2743e028 .. 0x274be028 .. 0x2753e028 >>> msection 171: 0x2753f028 .. 0x275bf028 .. 0x2763f028 >>> msection 172: 0x27640028 .. 0x276c0028 .. 0x27740028 >>> msection 173: 0x27741028 .. 0x277c1028 .. 0x27841028 >>> msection 174: 0x27842028 .. 0x278c2028 .. 0x27942028 >>> msection 175: 0x27943028 .. 0x279c3028 .. 0x27a43028 >>> msection 176: 0x27a44028 .. 0x27ac4028 .. 0x27b44028 >>> msection 177: 0x27b45028 .. 0x27bc5028 .. 0x27c45028 >>> msection 178: 0x27c46028 .. 0x27cc6028 .. 0x27d46028 >>> msection 179: 0x27d47028 .. 0x27dc7028 .. 0x27e47028 >>> msection 180: 0x27e48028 .. 0x27ec8028 .. 0x27f48028 >>> msection 181: 0x27f49028 .. 0x27fc9028 .. 0x28049028 >>> msection 182: 0x2804a028 .. 0x280ca028 .. 0x2814a028 >>> msection 183: 0x2814b028 .. 0x281cb028 .. 0x2824b028 >>> msection 184: 0x2824c028 .. 0x282cc028 .. 0x2834c028 >>> msection 185: 0x2834d028 .. 0x283cd028 .. 0x2844d028 >>> msection 186: 0x2844e028 .. 0x284ce028 .. 0x2854e028 >>> msection 187: 0x2854f028 .. 0x285cf028 .. 0x2864f028 >>> msection 188: 0x28650028 .. 0x286d0028 .. 0x28750028 >>> msection 189: 0x28751028 .. 0x287d1028 .. 0x28851028 >>> msection 190: 0x28852028 .. 0x288d2028 .. 0x28952028 >>> msection 191: 0x28953028 .. 0x289d3028 .. 0x28a53028 >>> msection 192: 0x28a54028 .. 0x28ad4028 .. 0x28b54028 >>> msection 193: 0x28b55028 .. 0x28bd5028 .. 0x28c55028 >>> msection 194: 0x28c56028 .. 0x28cd6028 .. 0x28d56028 >>> msection 195: 0x28d57028 .. 0x28dd7028 .. 0x28e57028 >>> msection 196: 0x28e58028 .. 0x28ed8028 .. 0x28f58028 >>> msection 197: 0x28f59028 .. 0x28fd9028 .. 0x29059028 >>> msection 198: 0x2905a028 .. 0x290da028 .. 0x2915a028 >>> msection 199: 0x2915b028 .. 0x291db028 .. 0x2925b028 >>> msection 200: 0x2925c028 .. 0x292dc028 .. 0x2935c028 >>> msection 201: 0x2935d028 .. 0x293dd028 .. 0x2945d028 >>> msection 202: 0x2945e028 .. 0x294de028 .. 0x2955e028 >>> msection 203: 0x2955f028 .. 0x295df028 .. 0x2965f028 >>> msection 204: 0x29660028 .. 0x296e0028 .. 0x29760028 >>> msection 205: 0x29761028 .. 0x297e1028 .. 0x29861028 >>> msection 206: 0x29862028 .. 0x298e2028 .. 0x29962028 >>> msection 207: 0x29963028 .. 0x299e3028 .. 0x29a63028 >>> msection 208: 0x29a64028 .. 0x29ae4028 .. 0x29b64028 >>> msection 209: 0x29b65028 .. 0x29be5028 .. 0x29c65028 >>> msection 210: 0x29c66028 .. 0x29ce6028 .. 0x29d66028 >>> msection 211: 0x29d67028 .. 0x29de7028 .. 0x29e67028 >>> msection 212: 0x29e68028 .. 0x29ee8028 .. 0x29f68028 >>> msection 213: 0x29f69028 .. 0x29fe9028 .. 0x2a069028 >>> msection 214: 0x2a06a028 .. 0x2a0ea028 .. 0x2a16a028 >>> msection 215: 0x2a16b028 .. 0x2a1eb028 .. 0x2a26b028 >>> msection 216: 0x2a26c028 .. 0x2a2ec028 .. 0x2a36c028 >>> msection 217: 0x2a36d028 .. 0x2a3ed028 .. 0x2a46d028 >>> msection 218: 0x2a46e028 .. 0x2a4ee028 .. 0x2a56e028 >>> msection 219: 0x2a56f028 .. 0x2a5ef028 .. 0x2a66f028 >>> msection 220: 0x2a670028 .. 0x2a6f0028 .. 0x2a770028 >>> msection 221: 0x2a771028 .. 0x2a7f1028 .. 0x2a871028 >>> msection 222: 0x2a872028 .. 0x2a8f2028 .. 0x2a972028 >>> msection 223: 0x2a973028 .. 0x2a9f3028 .. 0x2aa73028 >>> msection 224: 0x2aa74028 .. 0x2aaf4028 .. 0x2ab74028 >>> msection 225: 0x2ab75028 .. 0x2abf5028 .. 0x2ac75028 >>> msection 226: 0x2ac76028 .. 0x2acf6028 .. 0x2ad76028 >>> msection 227: 0x2ad77028 .. 0x2adf7028 .. 0x2ae77028 >>> msection 228: 0x2ae78028 .. 0x2aef8028 .. 0x2af78028 >>> msection 229: 0x2af79028 .. 0x2aff9028 .. 0x2b079028 >>> msection 230: 0x2b07a028 .. 0x2b0fa028 .. 0x2b17a028 >>> msection 231: 0x2b17b028 .. 0x2b1fb028 .. 0x2b27b028 >>> msection 232: 0x2b27c028 .. 0x2b2fc028 .. 0x2b37c028 >>> msection 233: 0x2b37d028 .. 0x2b3fd028 .. 0x2b47d028 >>> msection 234: 0x2b47e028 .. 0x2b4fe028 .. 0x2b57e028 >>> msection 235: 0x2b57f028 .. 0x2b5ff028 .. 0x2b67f028 >>> msection 236: 0x2b680028 .. 0x2b700028 .. 0x2b780028 >>> msection 237: 0x2b781028 .. 0x2b801028 .. 0x2b881028 >>> msection 238: 0x2b882028 .. 0x2b902028 .. 0x2b982028 >>> msection 239: 0x2b983028 .. 0x2ba03028 .. 0x2ba83028 >>> msection 354: 0x32cf6028 .. 0x32d76028 .. 0x32df6028 >>> msection 355: 0x32df7028 .. 0x32e77028 .. 0x32ef7028 >>> msection 356: 0x32ef8028 .. 0x32f78028 .. 0x32ff8028 >>> msection 357: 0x32ff9028 .. 0x33079028 .. 0x330f9028 >>> msection 358: 0x330fa028 .. 0x3317a028 .. 0x331fa028 >>> msection 359: 0x331fb028 .. 0x3327b028 .. 0x332fb028 >>> msection 360: 0x332fc028 .. 0x3337c028 .. 0x333fc028 >>> msection 361: 0x333fd028 .. 0x3347d028 .. 0x334fd028 >>> msection 362: 0x334fe028 .. 0x3357e028 .. 0x335fe028 >>> msection 363: 0x335ff028 .. 0x3367f028 .. 0x336ff028 >>> msection 364: 0x33700028 .. 0x33780028 .. 0x33800028 >>> msection 365: 0x33801028 .. 0x33881028 .. 0x33901028 >>> msection 366: 0x33902028 .. 0x33982028 .. 0x33a02028 >>> msection 367: 0x33a03028 .. 0x33a83028 .. 0x33b03028 >>> msection 368: 0x33b04028 .. 0x33b84028 .. 0x33c04028 >>> msection 369: 0x33c05028 .. 0x33c85028 .. 0x33d05028 >>> msection 370: 0x33d06028 .. 0x33d86028 .. 0x33e06028 >>> msection 371: 0x33e07028 .. 0x33e87028 .. 0x33f07028 >>> msection 372: 0x33f08028 .. 0x33f88028 .. 0x34008028 >>> msection 373: 0x34009028 .. 0x34089028 .. 0x34109028 >>> msection 374: 0x3410a028 .. 0x3418a028 .. 0x3420a028 >>> msection 375: 0x3420b028 .. 0x3428b028 .. 0x3430b028 >>> msection 376: 0x3430c028 .. 0x3438c028 .. 0x3440c028 >>> msection 377: 0x3440d028 .. 0x3448d028 .. 0x3450d028 >>> msection 378: 0x3450e028 .. 0x3458e028 .. 0x3460e028 >>> msection 379: 0x3460f028 .. 0x3468f028 .. 0x3470f028 >>> msection 380: 0x34710028 .. 0x34790028 .. 0x34810028 >>> msection 381: 0x34811028 .. 0x34891028 .. 0x34911028 >>> msection 382: 0x34912028 .. 0x34992028 .. 0x34a12028 >>> msection 383: 0x34a13028 .. 0x34a93028 .. 0x34b13028 >>> msection 384: 0x34b14028 .. 0x34b94028 .. 0x34c14028 >>> msection 385: 0x34c15028 .. 0x34c95028 .. 0x34d15028 >>> msection 386: 0x34d16028 .. 0x34d96028 .. 0x34e16028 >>> msection 387: 0x34e17028 .. 0x34e97028 .. 0x34f17028 >>> msection 388: 0x34f18028 .. 0x34f98028 .. 0x35018028 >>> msection 389: 0x35019028 .. 0x35099028 .. 0x35119028 >>> msection 390: 0x3511a028 .. 0x3519a028 .. 0x3521a028 >>> msection 391: 0x3521b028 .. 0x3529b028 .. 0x3531b028 >>> msection 392: 0x3531c028 .. 0x3539c028 .. 0x3541c028 >>> msection 393: 0x3541d028 .. 0x3549d028 .. 0x3551d028 >>> msection 394: 0x3551e028 .. 0x3559e028 .. 0x3561e028 >>> msection 395: 0x3561f028 .. 0x3569f028 .. 0x3571f028 >>> msection 396: 0x35720028 .. 0x357a0028 .. 0x35820028 >>> msection 397: 0x35821028 .. 0x358a1028 .. 0x35921028 >>> msection 398: 0x35922028 .. 0x359a2028 .. 0x35a22028 >>> msection 399: 0x35a23028 .. 0x35aa3028 .. 0x35b23028 >>> msection 400: 0x35b24028 .. 0x35ba4028 .. 0x35c24028 >>> msection 401: 0x35c25028 .. 0x35ca5028 .. 0x35d25028 >>> msection 402: 0x35d26028 .. 0x35da6028 .. 0x35e26028 >>> msection 403: 0x35ea4028 .. 0x35f24028 .. 0x35fa4028 >>> msection 404: 0x36009028 .. 0x36089028 .. 0x36109028 >>> msection 405: 0x3610a028 .. 0x3618a028 .. 0x3620a028 >>> msection 406: 0x3620b028 .. 0x3628b028 .. 0x3630b028 >>> msection 407: 0x3630c028 .. 0x3638c028 .. 0x3640c028 >>> msection 408: 0x3640d028 .. 0x3648d028 .. 0x3650d028 >>> msection 409: 0x3650e028 .. 0x3658e028 .. 0x3660e028 >>> msection 410: 0x3660f028 .. 0x3668f028 .. 0x3670f028 >>> msection 411: 0x36710028 .. 0x36790028 .. 0x36810028 >>> msection 412: 0x36811028 .. 0x36891028 .. 0x36911028 >>> msection 413: 0x36912028 .. 0x36992028 .. 0x36a12028 >>> msection 414: 0x36a13028 .. 0x36a93028 .. 0x36b13028 >>> msection 415: 0x36b14028 .. 0x36b94028 .. 0x36c14028 >>> msection 416: 0x36c15028 .. 0x36c95028 .. 0x36d15028 >>> msection 417: 0x36d16028 .. 0x36d96028 .. 0x36e16028 >>> msection 418: 0x36e17028 .. 0x36e97028 .. 0x36f17028 >>> msection 419: 0x36f18028 .. 0x36f98028 .. 0x37018028 >>> msection 420: 0x37019028 .. 0x37099028 .. 0x37119028 >>> msection 421: 0x3711a028 .. 0x3719a028 .. 0x3721a028 >>> msection 422: 0x3721b028 .. 0x3729b028 .. 0x3731b028 >>> msection 423: 0x3731c028 .. 0x3739c028 .. 0x3741c028 >>> msection 424: 0x3741d028 .. 0x3749d028 .. 0x3751d028 >>> msection 425: 0x3751e028 .. 0x3759e028 .. 0x3761e028 >>> msection 426: 0x3761f028 .. 0x3769f028 .. 0x3771f028 >>> msection 427: 0x37720028 .. 0x377a0028 .. 0x37820028 >>> msection 428: 0x37821028 .. 0x378a1028 .. 0x37921028 >>> msection 429: 0x4085d028 .. 0x408dd028 .. 0x4095d028 >>> msection 430: 0x4095e028 .. 0x409de028 .. 0x40a5e028 >>> msection 431: 0x40a5f028 .. 0x40adf028 .. 0x40b5f028 >>> msection 432: 0x417c8028 .. 0x41848028 .. 0x418c8028 >>> msection 433: 0x41f25028 .. 0x41fa5028 .. 0x42025028 >>> msection 434: 0x42026028 .. 0x420a6028 .. 0x42126028 >>> msection 435: 0x42127028 .. 0x421a7028 .. 0x42227028 >>> msection 436: 0x4223f028 .. 0x422bf028 .. 0x4233f028 >>> msection 437: 0x4236b028 .. 0x423eb028 .. 0x4246b028 >>> msection 438: 0x4250f028 .. 0x4258f028 .. 0x4260f028 >>> alloc_msection = 0x31ce6008 >>> stack_msection = 0x00000000 >>> heap_msection = 0x31ce6008 >>> scan_msection = 0x31ce6008 >>> alloc_stack_ptr = 0x31e64e88 >>> alloc_stack_limit = 0x31de7028 >>> alloc_heap_limit = 0x31de6028 >>> alloc_heap_ptr = 0x31d77548 >>> scan_ptr = 0x31d77548 >>> scan_msection->alloc = 0x31dd6228 >>> The object 0x0c966cb3 should be ___MOVABLE0 >>> body[-1] = 0x0c946091 >>> #( >>> #(...) >>> PROCEDURE >>> #(...) >>> 53 >>> #(...) >>> #(...) >>> #(...) >>> #(...) >>> ) >>> body[ 0] = 0x00dd4f61 >>> PROCEDURE >>> body[ 1] = 0x0c946041 >>> #( >>> #(...) >>> (...) >>> ) >>> body[ 2] = 0x000000d4 >>> 53 >>> body[ 3] = 0x0c90eb91 >>> #( >>> #(...) >>> #f >>> #f >>> #f >>> #f >>> #f >>> #f >>> #f >>> ) >>> body[ 4] = 0x0c9894a1 >>> STRING >>> body[ 5] = 0x00001008 >>> 1026 >>> body[ 6] = 0x0c92ee53 >>> ( >>> SYMBOL >>> . >>> (...) >>> ) >>> body[ 7] = 0x00d279c1 >>> SYMBOL >>> body[ 8] = 0x00003000 >>> 3072 >>> body[ 9] = 0x0c946181 >>> #( >>> #(...) >>> PROCEDURE >>> #(...) >>> 54 >>> #(...) >>> #(...) >>> #(...) >>> #(...) >>> ) >>> The reference was found in a will list |dig-out-gc-roots-graph| / |##resolve-referencing-objects| work well enough for my use, though for including them in Gambit it would be good that they're stable. It's funny that the crash happens _during_ GC. Could it be that |##resolve-referencing-objects| picks up some object references that are so Gambit-internal that just the fact that there's a reference to it makes the GC crash? Any thought on how fix? 2013/6/19 Mikael <mikael.rcv(a)gmail.com>

1 0

How introspect #<frame #[number]> objects?
by Mikael 20 Jui '13

20 Jui '13

Dear Marc, In memory leak hunting I've gotten to a place where there's two stack frame objects that keep the leaking pointer. How can I introspect #<frame #[number]> objects to understand where in the sourcecode they come from in terms of location, code content and variable content? Thanks, Mikael

1 0

|dig-out-gc-roots-graph|, a routine for digging out the graph of GC roots for a given object: Code & use examples
by Mikael 20 Jui '13

20 Jui '13

Here is |dig-out-gc-roots-graph|, a routine for digging out the GC roots for a given object. As potentially the depth to the deepest root can be really deep and each resolve operation takes one full GC to perform which can take seconds, the probing is done one level of depth at a time rather than through ordinary tree recursion, and after each probe the complete result up to that point is printed out. ** BETA NOTICE: |dig-out-gc-roots-graph| works well enough for my current use though there is a stability issue about |dig-out-gc-roots-graph| or |##resolve-referencing-objects| addressed in the next email - *this version tends to crash Gambit during GC* after having worked itself some levels into the graph. At least if it will become perfectly stable, this will be released on the dumping grounds and then as a module file in a repo or alike at some future point in time. *Usage example 1:* > (dig-out-gc-roots-graph '(1 2 3)) Digging out the GC roots for object #2... References to object #2: #2 (Unknown root) #3 (In work queue) References to object #2: #2 (Unknown root) #3 (Unknown root) #4 (In work queue) References to object #2: #2 (Unknown root) #3 (Unknown root) #4 (Unknown root) #3 (In work queue) #5 (In work queue) #6 (In work queue) References to object #2: #2 (Unknown root) #3 (Unknown root) #4 (Unknown root) #3 (In work queue) #5 (In work queue) #6 (Unknown root) #4 (In work queue) References to object #2: #2 (Unknown root) #3 (Unknown root) #4 (Unknown root) #3 (In work queue) #5 (Unknown root) #6 (Unknown root) #4 (In work queue) References to object #2: #2 (Unknown root) #3 (Unknown root) #4 (Unknown root) #3 (This object was already found at a lower depth in the graph.) #5 (Unknown root) #6 (Unknown root) #4 (In work queue) References to object #2: #2 (Unknown root) #3 (Unknown root) #4 (Unknown root) #3 (This object was already found at a lower depth in the graph.) #5 (Unknown root) #6 (Unknown root) #4 (This object was already found at a lower depth in the graph.) Done! All the objects that refer to this object in total (+ the object itself) are: #5 #4 #6 #2 #3 All the objects that refer to this object closest to the root in total are: #5 > #3 #(#(#f #<procedure #4 ##cprc-app1-sub> #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#( [...] "(Unknown root)" should be the interpreter's reference accessible as the # variable in the REPL. #3 must be some structure created by the interpreter, and so are the objects that reference it in turn (i.e. #4, #5 & #6). Curious what they are about? *Usage example 2:* > (define a "Hello world") > (define b (list a a)) > (define c (list b b)) > (dig-out-gc-roots-graph a) Digging out the GC roots for object #2... References to object #2: #2 (Unknown root) #3 (In work queue) #4 (In work queue) References to object #2: #2 (Unknown root) #3 (In work queue) #4 (Unknown root) #5 (In work queue) #6 (In work queue) References to object #2: #2 (Unknown root) #3 (Unknown root) #4 (In work queue) #4 (Unknown root) #5 (In work queue) #6 (In work queue) References to object #2: #2 (Unknown root) #3 (Unknown root) #4 (In work queue) #4 (Unknown root) #5 (In work queue) #6 (Unknown root) References to object #2: #2 (Unknown root) #3 (Unknown root) #4 (In work queue) #4 (Unknown root) #5 (Unknown root) #6 (In work queue) #6 (Unknown root) References to object #2: #2 (Unknown root) #3 (Unknown root) #4 (This object was already found at a lower depth in the graph.) #4 (Unknown root) #5 (Unknown root) #6 (In work queue) #6 (Unknown root) References to object #2: #2 (Unknown root) #3 (Unknown root) #4 (This object was already found at a lower depth in the graph.) #4 (Unknown root) #5 (Unknown root) #6 (This object was already found at a lower depth in the graph.) #6 (Unknown root) Done! All the objects that refer to this object in total (+ the object itself) are: #3 #2 #4 #6 #5 All the objects that refer to this object closest to the root in total are: #6 > (object->serial-number a) 2 > (object->serial-number b) 4 > (object->serial-number (cdr b)) 3 > (object->serial-number c) 6 > (object->serial-number (cdr c)) 5 "(Unknown root)" are either the global object reference (this is the case for the reports of #2, #4 and #6), or some other reference that Gambit holds - that would be the reports for #3 and #5, would be curious to know what they are! *Usage example 3:* > (define a "Obj") > (define b (make-will a (lambda (v) (void)))) > (dig-out-gc-roots-graph a) Digging out the GC roots for object #2... References to object #2: #2 (Unknown root) Done! All the objects that refer to this object in total (+ the object itself) are: #2 All the objects that refer to this object closest to the root in total are: #2 Weak references are not covered, as it should be. *Files & notes* First, attached the latest Gambit commit's (ffd839c64f66278cdb4cce5ef86316ee290a4204) files patched with ##resolve-referencing-objects support. Next, dig-out-gc-roots-graph.scm containing |dig-out-gc-roots-graph| . For |dig-out-gc-roots-graph| to work, dig-out-gc-roots-graph.scm must be in compiled mode, otherwise it produces an infinite amount of yet-another-referencing-object.

1 0

The #<absent> behaves differently as argument on call to interpreted vs to compiled procedure, interesting.
by Mikael 19 Jui '13

19 Jui '13

For anyone interested, on a 64bit installation: f.scm contains: (define (proc arg) (list 'proc-got-arg: arg)) $ gsc Gambit v4.6.9 > (compile-file "f.scm") (load "f.o1") > (proc (##encoding->object #xffffffffffffffea)) (proc-got-arg: #<absent>) > (define (proc arg) (list 'proc-got-arg: arg)) > (proc (##encoding->object #xffffffffffffffea)) *** ERROR IN (console)(a)4.1 -- Wrong number of arguments passed to procedure (proc) 1> In interpreted mode, any absent object passed as argument disappears. This has the funny consequence that a procedure overlapping ##wr must be compiled, (define original-wr ##wr) (set! ##wr (lambda (write-env obj) (original-wr write-env obj))) (##encoding->object #xffffffffffffffea) this only works if it's compiled.

2 1

Any procedure/debug way to see what objects reference an object?
by Mikael 18 Jui '13

18 Jui '13

Dear Marc, I'm having a memory leak issue that takes hours and hours to resolve. Is there any way to traverse the heap as to find the object that references a particular object? E.g. (object-references object) => referencing-objects-list It's completely OK if it requires scanning all the heap :} If it's not in Gambit already, I guess one such routine could be created easily-enough based on the GC mark routines. Thanks, Mikael

2 9