Closed Bug 378261 Opened 17 years ago Closed 17 years ago

Provide heap dumping alternatives for all users of js_DumpGCHeap

Categories

(Core :: XPConnect, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: igor, Assigned: igor)

References

Details

Attachments

(2 files, 7 obsolete files)

xpcshell should define the same dumpHeap function that js shell provides and remove no longer functional GC_MARK_DEBUG code.
Attached patch dumpHeap fpr xpcshell (obsolete) — Splinter Review
The patch removes GC_MARK_DEBUG code and adds dumpHeap, a carbon copy from js.c
Attachment #262343 - Flags: review?(brendan)
Attachment #262343 - Flags: review?(brendan) → review+
I am making the bug more generic to switch xpcshell and jsd code that relies on GC_MARK_DEBUG-only js_DumpGCHeap to use new tracing API instead in one go.
Summary: Defining dumpHeap in xpcshell → Provide heap dumping alternatives for all users of js_DumpGCHeap
Attached patch JS_DumpHeap (obsolete) — Splinter Review
The patch does 4 things:

1. It adds JS_TraceRuntime to jsapi.h so external tracers can use it to enumerate all the roots.

2. It replaces js_NewGCHeapDumper/js_FreeGCHeapDumper by a single DEBUG-only JS_DumpHeap from jsapi.h. The flexibility offered by the pair is not worth the code bloat even if it happens with DEBUG-only code. Not to depend on stdio.h, the function dumps the heap into a C string. I also moved the implementation of JS_DumpHeap into jsapi.c as it has very little to do with GC. Note that the implementation is essentially rewritten and generates output in 2 phases, first to build the tree representing the graph and then serializing the tree. The serialization code also fixes few bugs with printing of the chain leading into the particular thing. In the previous version I forgot that node.edgeName is the name of the edge leading into the node, not from the node. 

3. DumpHeap is both js.c and xpcshell.c uses the new function to dump the heap into a file.

4. JS debugger is extended with "void DumpHeap()" method. I suspect that a better signature return the result of JS_DumpHeap and adds few parameters to customize JS_DumpHeap call. But I really do not how useful that would be.
Attachment #262343 - Attachment is obsolete: true
Attachment #262421 - Flags: review?(brendan)
> Not to depend on stdio.h, the function dumps the heap into a C string.

How well does that work for multi-hundred-megabyte dumps?
(In reply to comment #4)
> > Not to depend on stdio.h, the function dumps the heap into a C string.
> 
> How well does that work for multi-hundred-megabyte dumps?

Not very well obviously but given the sequent access to the chars and single malloc call without realloc it should work as long as there is enough memory. But note that JS_DumpHeap is written itself in terms of public API so the code can be copied and customized to dump the graph in what ever form that is necessary. So what would be the typical case for heap dumping?

The typical case for heap dumping for me is debugging leaks.  In the typical such case, the heap at dump time contains JSObjects corresponding to every single DOM Node, Document, and Window in all the tabs and windows that are open.  Heap dumps of over 100MB in size are not at all uncommon.

For my purposes, just having the XPConnect code that dumps at shutdown dump directly to a file would be fine, honestly.
It used to be the case that one could compile with GC_MARK_DEBUG, set js_DumpGCHeap to a FILE *, and capture dumps. We should try to preserve the stdio capability, even as we eliminate the #ifdefs and the extern FILE * variable. That's my view of compatibility, anyway.

/be
(In reply to comment #7)
> It used to be the case that one could compile with GC_MARK_DEBUG, set
> js_DumpGCHeap to a FILE *, and capture dumps. We should try to preserve the
> stdio capability, even as we eliminate the #ifdefs and the extern FILE *
> variable. That's my view of compatibility, anyway.

OK, I will then change JS_DumpHeap signature from:

JS_PUBLIC_API(char *)
JS_DumpHeap(JSContext *cx, void* startThing, uint32 startKind,
            void *thingToFind, size_t maxDepth, void *thingToIgnore)

to:

JS_PUBLIC_API(JSBool)
JS_DumpHeap(JSContext *cx, void* startThing, uint32 startKind,
            void *thingToFind, size_t maxDepth, void *thingToIgnore,
            JSPrintfMethod printer, void *closure)

where 

typedef int (*JSPrintfMethod)(void *closure, const char *format, ...)

In this way one can simply pass fprintf and FILE* to DumpHeap to output to a file.

(In reply to comment #6)
> For my purposes, just having the XPConnect code that dumps at shutdown dump
> directly to a file would be fine, honestly.

I will also extend the patch to print the dump on shutdown based on an environment variable. 
Attached patch JS_DumpHeap v2 (obsolete) — Splinter Review
Here is a scalable version of JS_DumpHeap that takes printf format function as argument so one can pass fprintf there. I also changed the dump implementation not to use the recursion so it should be able to dump an arbitrary object graph.

The patch does not include optional dumping on shutdown as I do not know where to put a call JS_DumpHeap, I will do it later within bug 375270.
Attachment #262421 - Attachment is obsolete: true
Attachment #262544 - Flags: review?(brendan)
Attachment #262421 - Flags: review?(brendan)
Comment on attachment 262544 [details] [diff] [review]
JS_DumpHeap v2

>+  not_traceable_arg:
>+    fprintf(gErrFile, "dumpHeap: "
>+            "the argument %u is not null or a heap-allocated thing\n",

s/the argument/argument/

"the argument 0 ..." is misleading -- does it mean 0 passed as an actual arg, or argv[0]? We want the latter, and just "argument 0" is one way of saying that more precisely. There's no doubt an even clearer way, but I can't think of it atm.


>+typedef struct JSDumpingTracer
>+{

Nit: { on same line as typedef struct ...


>+    /*
>+     * We need to print the parent chain in the reverse order. To do it in
>+     * O(N) time where N is the chain length we first revert the chain while

s/revert/reverse/

>+     * seraching for the top and then print each node while restoring the

"searching" misspelled.


>+            /* Descend into children. */
>+            if (dtrc.ok &&
>+                depth < maxDepth &&
>+                (thingToFind != node->thing || !thingToFindWasTraced)) {
>+                dtrc.parentNode = node;
>+                children = NULL;
>+                dtrc.lastNodep = &children;
>+                JS_TraceChildren(&dtrc.base, node->thing, node->kind);
>+                if (thingToFind == node->thing)
>+                    thingToFindWasTraced = JS_TRUE;

Won't this find only the first path to thingToFind? As you note, we never found all paths, but we used to report all the ones that went through disjoint sets of nodes.

> #ifdef DEBUG
> extern JS_PUBLIC_API(void)
> JS_PrintTraceThingInfo(char *buf, size_t bufsize, JSTracer *trc,
>                        void *thing, uint32 kind, JSBool includeDetails);

Need a blank line here.

>+/*
>+ * DEBUG-only method to dump an object graph of heap-allocated things.
>+ *
>+ * start: when non-null, dump only things reachable from start thing. Otherwise
>+ *        dump all things rechable from runtime roots.
>+ * startKind: trace kind of start if start is not null. Must be 0 when start
>+ *            is null.
>+ * thingToFind: dump only paths in the object graph leading to thingToFind
>+ *              when non-null.
>+ * maxDepth: the upper bound on the number of edges to descend from the graph
>+ *           roots.
>+ * thingToIgnore: thing to ignore during graph traversal when non-null.
>+ * format: callback to format the dump output.
>+ * closure: an argument to pass to formater.
>+ */
>+extern JS_PUBLIC_API(JSBool)
>+JS_DumpHeap(JSContext *cx, void* startThing, uint32 startKind,
>+            void *thingToFind, size_t maxDepth, void *thingToIgnore,
>+            JSPrintfFormater format, void *closure);
> #endif

/be
(In reply to comment #10)
> >+            /* Descend into children. */
> >+            if (dtrc.ok &&
> >+                depth < maxDepth &&
> >+                (thingToFind != node->thing || !thingToFindWasTraced)) {
> >+                dtrc.parentNode = node;
> >+                children = NULL;
> >+                dtrc.lastNodep = &children;
> >+                JS_TraceChildren(&dtrc.base, node->thing, node->kind);
> >+                if (thingToFind == node->thing)
> >+                    thingToFindWasTraced = JS_TRUE;
> 
> Won't this find only the first path to thingToFind? As you note, we never found
> all paths, but we used to report all the ones that went through disjoint sets
> of nodes.

To find all the things that are reachable from thingToFind and also refer directly to thingToFind one needs to descend into thingToFind once. On the other hand one wants to add a node to the dump tree each time thingToFind is reached during the graph traversal and this is exactly what is the patch doing. To witness the following patch prints all things reachable from global roots that refers to the global object:

js> dumpHeap(null, null, this)
dumpHeap(null, null, this)
0x872a420 global 0               via variables
0x872a420 global 0               via variables(0x872a420 global).__proto__(0x872a500 Object).__parent__
0x872a420 global 0               via variables(0x872a420 global).__proto__(0x872a500 Object).toSource(0x872a540 Function).__proto__(0x872a440 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).CLASS_OBJECT(Object)(0x872a520 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).CLASS_OBJECT(Function)(0x872a460 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).CLASS_OBJECT(Array)(0x872ab80 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).CLASS_OBJECT(Array)(0x872ab80 Function).prototype(0x872ab60 Array).__parent__
0x872a420 global 0               via variables(0x872a420 global).version(0x872a700 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).options(0x872a720 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).load(0x872a740 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).readline(0x872a760 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).print(0x872a780 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).help(0x872a7a0 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).quit(0x872a7c0 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).gc(0x872a7e0 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).trap(0x872a820 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).untrap(0x872a840 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).line2pc(0x872a860 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).pc2line(0x872a880 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).stringsAreUTF8(0x872a8a0 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).testUTF8(0x872a8c0 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).throwError(0x872a8e0 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).dis(0x872a900 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).dissrc(0x872a920 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).notes(0x872a960 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).tracing(0x872a980 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).stats(0x872a9a0 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).build(0x872a9c0 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).clear(0x872a9e0 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).intern(0x872aa00 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).clone(0x872aa20 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).seal(0x872aa40 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).getpda(0x872aa60 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).getslx(0x872aa80 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).toint32(0x872aaa0 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).evalcx(0x872aac0 Function).__parent__
0x872a420 global 0               via variables(0x872a420 global).it(0x872aae0 It).__parent__
0x872a420 global 0               via variables(0x872a420 global).environment(0x872ab40 environment).__parent__
0x872a420 global 0               via this
0x872a420 global 0               via arg[2]
0x872a420 global 0               via scope chain
0x872a420 global 0               via variables
0x872a420 global 0               via operand[0](0x872a940 Function).__parent__
0x872a420 global 0               via operand[1]
0x872a420 global 0               via operand[4]
0x872a420 global 0               via this
0x872a420 global 0               via scope chain
0x872a420 global 0               via global object
0x872a420 global 0               via newborn object(0x872b100 Array).__parent__
js>      
Attached patch JS_DumpHeap v3 (obsolete) — Splinter Review
Besides addressing the nits the patch also fixes the number of arguments for DumpHeap declaration in js.c and makes makes calls to JS_DumpHeapa with startThing == thingToFind useful. With the previously patch it would print nothing but now it correctly prints each time thingToFind is reached trough thingToFind:

~/m/trunk/mozilla/js/src> ./Linux_All_DBG.OBJ/js 
js> dumpHeap(null, Math, Math)
dumpHeap(null, Math, Math)
0x8da0120 Math 8da0140           via __parent__(0x8d9f420 global).Math
0x8da0120 Math 8da0140           via toSource(0x8da0140 Function).__parent__
0x8da0120 Math 8da0140           via abs(0x8da0160 Function).__parent__
0x8da0120 Math 8da0140           via acos(0x8da0180 Function).__parent__
0x8da0120 Math 8da0140           via asin(0x8da01a0 Function).__parent__
0x8da0120 Math 8da0140           via atan(0x8da01c0 Function).__parent__
0x8da0120 Math 8da0140           via atan2(0x8da01e0 Function).__parent__
0x8da0120 Math 8da0140           via ceil(0x8da0200 Function).__parent__
0x8da0120 Math 8da0140           via cos(0x8da0220 Function).__parent__
0x8da0120 Math 8da0140           via exp(0x8da0240 Function).__parent__
0x8da0120 Math 8da0140           via floor(0x8da0260 Function).__parent__
0x8da0120 Math 8da0140           via log(0x8da0280 Function).__parent__
0x8da0120 Math 8da0140           via max(0x8da02a0 Function).__parent__
0x8da0120 Math 8da0140           via min(0x8da02c0 Function).__parent__
0x8da0120 Math 8da0140           via pow(0x8da02e0 Function).__parent__
0x8da0120 Math 8da0140           via random(0x8da0300 Function).__parent__
0x8da0120 Math 8da0140           via round(0x8da0320 Function).__parent__
0x8da0120 Math 8da0140           via sin(0x8da0340 Function).__parent__
0x8da0120 Math 8da0140           via sqrt(0x8da0360 Function).__parent__
0x8da0120 Math 8da0140           via tan(0x8da0380 Function).__parent__
Attachment #262544 - Attachment is obsolete: true
Attachment #262604 - Flags: review?(brendan)
Attachment #262544 - Flags: review?(brendan)
Attached patch JS_DumpHeap v4 (obsolete) — Splinter Review
In the previous patch I forgot to fix DumpHeap copy in xpcshell.
Attachment #262604 - Attachment is obsolete: true
Attachment #262606 - Flags: review?(brendan)
Attachment #262604 - Flags: review?(brendan)
Comment on attachment 262606 [details] [diff] [review]
JS_DumpHeap v4

>+        /*
>+         * Loop must be finished even when !dtrc.ok to free all so far
>+         * allocated nodes.

Nit: "all nodes allocated so far" reads better.

r=me, good patch followup.

/be
Attachment #262606 - Flags: review?(brendan) → review+
Attached patch JS_DumpHeap v4b (obsolete) — Splinter Review
The patch to commit with comments improvement suggestion picked up.
Attachment #262606 - Attachment is obsolete: true
Attachment #262609 - Flags: review+
Attached patch JS_DumpHeap v5 (obsolete) — Splinter Review
Fixes:

1. ok is initilized in DumpNode from jsapi.c. Running a debug build of xpcshell showed that immediately.

2. DumpHeap in xpcshell.cpp uses gOutFile, not stdout for consistency.

3. The patch *include* jsd changes that I forgot to add the last time.
Attachment #262609 - Attachment is obsolete: true
Attachment #262611 - Flags: review?(brendan)
Attached patch JS_DumpHeap v6Splinter Review
The new version reflect changes timeless committed to js.c where he fixed the missing update to shell_help_messages and uses more intuitive defintion of maxDepth parameter of JS_DumpHeap. Now maxDepth means really the limit on the path length, not path length + 1 as before. Thus dumpHeap(null, null, null, 0) prints nothing while dumpHeap(null, null, null, 1) prints all things stored in the runtime's roots:

~/m/trunk/mozilla/js/src> ./Linux_All_DBG.OBJ/js
js> dumpHeap(null, null, null, 0)
dumpHeap(null, null, null, 0)
js> dumpHeap(null, null, null, 1)
dumpHeap(null, null, null, 1)
0xa0cf110 atom                   via pinned_atom[0]
0xa0ce1f0 atom Date              via pinned_atom[1]
0xa0ce058 atom null              via pinned_atom[3]
0xa0ce928 atom constructor       via pinned_atom[5]
0xa0ce290 atom String            via pinned_atom[6]
0xa0ceec0 atom namespace         via pinned_atom[7]
0xa0cec58 atom __noSuchMethod__  via pinned_atom[9]
0xa0ce1c0 atom Call              via pinned_atom[13]
0xa0ce0b8 atom Null              via pinned_atom[14]
0xa0cefe0 atom *::               via pinned_atom[15]
0xa0ce220 atom Math              via pinned_atom[16]
0xa0ce3d0 atom AnyName           via pinned_atom[19]
0xa0cef80 atom <                 via pinned_atom[20]
0xa0ce190 atom Boolean           via pinned_atom[21]
0xa0ce4f8 atom RangeError        via pinned_atom[23]
0xa0ce710 atom File              via pinned_atom[29]
0xa0ce5b8 atom TypeError         via pinned_atom[30]
0xa0ce300 atom Script            via pinned_atom[31]
0xa0ce990 atom each              via pinned_atom[33]
0xa0ce810 atom arguments         via pinned_atom[37]
0xa0ce740 atom Block             via pinned_atom[40]
0xa0ce6a0 atom StopIteration     via pinned_atom[41]
0xa0ce028 atom boolean           via pinned_atom[42]
0xa0ce368 atom Namespace         via pinned_atom[44]
0xa0cdff0 atom number            via pinned_atom[45]
0xa0d67e0 atom uneval            via pinned_atom[47]
0xa0d6698 atom unescape          via pinned_atom[48]
0xa0cea28 atom get               via pinned_atom[50]
0xa0cebb0 atom message           via pinned_atom[51]
0xa0ce9f8 atom fileName          via pinned_atom[52]
0xa0ce878 atom callee            via pinned_atom[56]
0xa0ceb38 atom length            via pinned_atom[57]
0xa0cecd0 atom __proto__         via pinned_atom[60]
0xa0cf010 atom >                 via pinned_atom[61]
0xa0ce628 atom Generator         via pinned_atom[62]
0xa0ce330 atom XML               via pinned_atom[63]
0xa0cee88 atom </                via pinned_atom[66]
0xa0ce158 atom Array             via pinned_atom[67]
0xa0cdf10 atom undefined         via pinned_atom[70]
0xa0d6578 atom isNaN             via pinned_atom[72]
0xa0ce9c0 atom eval              via pinned_atom[76]
0xa0cedd8 atom toString          via pinned_atom[77]
0xa0d65b0 atom isFinite          via pinned_atom[80]
0xa0cdfb8 atom string            via pinned_atom[81]
0xa0d6818 atom XMLList           via pinned_atom[84]
0xa0ce660 atom Iterator          via pinned_atom[85]
0xa0ce088 atom xml               via pinned_atom[86]
0xa0ce7d8 atom anonymous         via pinned_atom[88]
0xa0d66d0 atom decodeURI         via pinned_atom[90]
0xa0cee20 atom toLocaleString    via pinned_atom[91]
0xa0ce480 atom InternalError     via pinned_atom[94]
0xa0ce398 atom QName             via pinned_atom[95]
0xa0ce0f0 atom Object            via pinned_atom[96]
0xa0ceb00 atom __iterator__      via pinned_atom[97]
0xa0ce8b0 atom caller            via pinned_atom[98]
0xa0ce7a0 atom true              via pinned_atom[99]
0xa0d6758 atom decodeURIComponent via pinned_atom[100]
0xa0ced00 atom set               via pinned_atom[105]
0xa0ce8e8 atom prototype         via pinned_atom[106]
0xa0cdf80 atom function          via pinned_atom[107]
0xa0ce840 atom arity             via pinned_atom[108]
0xa0ce2c8 atom RegExp            via pinned_atom[109]
0xa0cea90 atom index             via pinned_atom[110]
0xa0ceda0 atom toSource          via pinned_atom[111]
0xa0d6628 atom parseInt          via pinned_atom[115]
0xa0d6510 atom NaN               via pinned_atom[116]
0xa0d6708 atom encodeURI         via pinned_atom[119]
0xa0ce580 atom SyntaxError       via pinned_atom[121]
0xa0ce4b8 atom EvalError         via pinned_atom[122]
0xa0cea60 atom getter            via pinned_atom[124]
0xa0cee58 atom valueOf           via pinned_atom[125]
0xa0ce410 atom AttributeName     via pinned_atom[126]
0xa0ceef0 atom />                via pinned_atom[127]
0xa0ceac0 atom input             via pinned_atom[128]
0xa0cef50 atom                   via pinned_atom[131]
0xa0d67a8 atom encodeURIComponent via pinned_atom[135]
0xa0ce960 atom __count__         via pinned_atom[136]
0xa0ce258 atom Number            via pinned_atom[137]
0xa0d6548 atom Infinity          via pinned_atom[140]
0xa0ce5f0 atom URIError          via pinned_atom[141]
0xa0cec10 atom next              via pinned_atom[142]
0xa0cef20 atom ::                via pinned_atom[143]
0xa0ce770 atom false             via pinned_atom[144]
0xa0ceb78 atom lineNumber        via pinned_atom[145]
0xa0ced68 atom stack             via pinned_atom[147]
0xa0ce128 atom Function          via pinned_atom[148]
0xa0ced38 atom setter            via pinned_atom[151]
0xa0d6850 atom isXMLName         via pinned_atom[154]
0xa0ce440 atom Error             via pinned_atom[156]
0xa0ce540 atom ReferenceError    via pinned_atom[157]
0xa0cefb0 atom *                 via pinned_atom[160]
0xa0cf040 atom close             via pinned_atom[161]
0xa0cec98 atom __parent__        via pinned_atom[162]
0xa0cebe0 atom name              via pinned_atom[163]
0xa0d65f0 atom parseFloat        via pinned_atom[164]
0xa0ce6e0 atom UnusedProto28     via pinned_atom[165]
0xa0d6660 atom escape            via pinned_atom[166]
0xa0cdf48 atom object            via pinned_atom[168]
0xa0cf420 global 0               via variables
0xa0d61c0 atom dumpHeap          via atom_table
0xa0cf940 Function a0d1ba0       via operand[0]
0xa0d0100 Array 0                via newborn object
0xa0cc170 string every           via newborn string
0xa0cbea8 double -inf            via newborn double
0xa0d2100 function every         via newborn private
js> dumpHeap(null, Math, null, 0)
dumpHeap(null, Math, null, 0)
js> dumpHeap(null, Math, null, 1)
dumpHeap(null, Math, null, 1)
0xa0da7c8 atom SQRT1_2           via id
0xa0da790 atom SQRT2             via id
0xa0daab8 atom PI                via id
0xa0daa88 atom LN10              via id
0xa0daa58 atom LN2               via id
0xa0daa28 atom LOG10E            via id
0xa0da9f0 atom LOG2E             via id
0xa0da9c0 atom E                 via id
0xa0da908 atom tan               via id
0xa0da8d8 atom sqrt              via id
0xa0da8a8 atom sin               via id
0xa0da878 atom round             via id
0xa0da848 atom random            via id
0xa0da828 atom pow               via id
0xa0da770 atom min               via id
0xa0da740 atom max               via id
0xa0da6c8 atom log               via id
0xa0da698 atom floor             via id
0xa0da668 atom exp               via id
0xa0da638 atom cos               via id
0xa0da5e0 atom ceil              via id
0xa0da568 atom atan2             via id
0xa0da538 atom atan              via id
0xa0da4f0 atom asin              via id
0xa0d6e68 atom acos              via id
0xa0d6d40 atom abs               via id
0xa0ceda0 atom toSource          via id
0xa0cf500 Object a0cf520         via __proto__
0xa0cf420 global 0               via __parent__
0xa0d0140 Function a0d2118       via toSource
0xa0d0160 Function a0d2130       via abs
0xa0d0180 Function a0d2148       via acos
0xa0d01a0 Function a0d2160       via asin
0xa0d01c0 Function a0d2178       via atan
0xa0d01e0 Function a0d2190       via atan2
0xa0d0200 Function a0d21a8       via ceil
0xa0d0220 Function a0d21c0       via cos
0xa0d0240 Function a0d21d8       via exp
0xa0d0260 Function a0d21f0       via floor
0xa0d0280 Function a0d2208       via log
0xa0d02a0 Function a0d2220       via max
0xa0d02c0 Function a0d2238       via min
0xa0d02e0 Function a0d2250       via pow
0xa0d0300 Function a0d2268       via random
0xa0d0320 Function a0d2280       via round
0xa0d0340 Function a0d2298       via sin
0xa0d0360 Function a0d22b0       via sqrt
0xa0d0380 Function a0d22c8       via tan
0xa0cc208 double 2.71828         via E
0xa0cc218 double 1.4427          via LOG2E
0xa0cc228 double 0.434294        via LOG10E
0xa0cc238 double 0.693147        via LN2
0xa0cc248 double 2.30259         via LN10
0xa0cc258 double 3.14159         via PI
0xa0cc268 double 1.41421         via SQRT2
0xa0cc278 double 0.707107        via SQRT1_2
js>
Attachment #262611 - Attachment is obsolete: true
Attachment #262658 - Flags: review?(brendan)
Attachment #262611 - Flags: review?(brendan)
Comment on attachment 262658 [details] [diff] [review]
JS_DumpHeap v6

Reordered jsd vs. src files frustrated interdiff, but I fixed manually (Firefox save-as needs better interaction design for frequent downloaders!) and it's all good.

/be
Attachment #262658 - Flags: review?(brendan) → review+
I committed the patch from comment 17 to the trunk:

Checking in src/js.c;
/cvsroot/mozilla/js/src/js.c,v  <--  js.c
new revision: 3.139; previous revision: 3.138
done
Checking in src/jsapi.c;
/cvsroot/mozilla/js/src/jsapi.c,v  <--  jsapi.c
new revision: 3.316; previous revision: 3.315
done
Checking in src/jsapi.h;
/cvsroot/mozilla/js/src/jsapi.h,v  <--  jsapi.h
new revision: 3.146; previous revision: 3.145
done
Checking in src/jsatom.c;
/cvsroot/mozilla/js/src/jsatom.c,v  <--  jsatom.c
new revision: 3.94; previous revision: 3.93
done
Checking in src/jsgc.c;
/cvsroot/mozilla/js/src/jsgc.c,v  <--  jsgc.c
new revision: 3.215; previous revision: 3.214
done
Checking in src/jsgc.h;
/cvsroot/mozilla/js/src/jsgc.h,v  <--  jsgc.h
new revision: 3.68; previous revision: 3.67
done
Checking in src/jspubtd.h;
/cvsroot/mozilla/js/src/jspubtd.h,v  <--  jspubtd.h
new revision: 3.80; previous revision: 3.79
done
Checking in src/xpconnect/shell/xpcshell.cpp;
/cvsroot/mozilla/js/src/xpconnect/shell/xpcshell.cpp,v  <--  xpcshell.cpp
new revision: 1.95; previous revision: 1.94
done
Checking in jsd/jsd_xpc.cpp;
/cvsroot/mozilla/js/jsd/jsd_xpc.cpp,v  <--  jsd_xpc.cpp
new revision: 1.79; previous revision: 1.78
done
Checking in jsd/idl/jsdIDebuggerService.idl;
/cvsroot/mozilla/js/jsd/idl/jsdIDebuggerService.idl,v  <--  jsdIDebuggerService.idl
new revision: 1.35; previous revision: 1.34
done
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Blocks: 378742
I assume js/src/README.html should get updated too?
Attached patch README.html fixSplinter Review
Attachment #262788 - Flags: review+
I committed README.html fix from comment 21 to the trunk:

Checking in README.html;
/cvsroot/mozilla/js/src/README.html,v  <--  README.html
new revision: 3.11; previous revision: 3.10
done
Blocks: 378255
this commit seems to have broken BeOS builds.  will file separate regression bug.
Blocks: 379165
No longer blocks: 379165
Depends on: 379165
Blocks: 475898
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: