← Back to branch summary

~ubuntu-branches/ubuntu/hardy/libgc/hardy-updates

« back to all changes in this revision

Viewing changes to doc/debugging.html

  • Committer: Bazaar Package Importer
  • Author(s): Ryan Murray
  • Date: 2005-02-03 00:50:53 UTC
  • mto: (3.1.1 etch) (1.2.4 upstream)
  • mto: This revision was merged to the branch mainline in revision 3.
  • Revision ID: james.westby@ubuntu.com-20050203005053-9c0v9r2qcm2g1cfp
Tags: upstream-6.4
Import upstream version 6.4

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/debugging.html
47
47
<PRE>
48
48
Needed to allocate blacklisted block at 0x...
49
49
</pre>
 
50
or
 
51
<PRE>
 
52
Repeated allocation of very large block ...
 
53
</pre>
50
54
when it needs to allocate a block at a location that it knows to be
51
55
referenced by a false pointer.  These false pointers can be either permanent
52
56
(<I>e.g.</i> a static integer variable that never changes) or temporary.
123
127
but were not cleared, or by caches growing without bounds.
124
128
<LI> Pointer misidentification.  The garbage collector is interpreting
125
129
integers or other data as pointers and retaining the "referenced"
126
 
objects.
 
130
objects.  A common symptom is that GC_dump() shows much of the heap
 
131
as black-listed.
127
132
<LI> Heap fragmentation.  This should never result in unbounded growth,
128
133
but it may account for larger heaps.  This is most commonly caused
129
134
by allocation of large objects.  On some platforms it can be reduced
180
185
<LI> Consider using <TT>GC_malloc_ignore_off_page()</tt>
181
186
to allocate large objects.  (See <TT>gc.h</tt> and above for details.
182
187
Large means &gt; 100K in most environments.)
 
188
<LI> If your heap size is larger than 100MB or so, build the collector with
 
189
-DLARGE_CONFIG.  This allows the collector to keep more precise black-list
 
190
information.
 
191
<LI> If you are using heaps close to, or larger than, a gigabyte on a 32-bit
 
192
machine, you may want to consider moving to a platform with 64-bit pointers.
 
193
This is very likely to resolve any false pointer issues.
183
194
</ol>
184
195
<H2>Prematurely Reclaimed Objects</h2>
185
196
The usual symptom of this is a segmentation fault, or an obviously overwritten
248
259
during which its block was last swept.
249
260
<LI> Verify that the offending object still has its correct contents at
250
261
this point.
251
 
The call <TT>GC_is_marked(p)</tt> from the debugger to verify that the
252
 
object has not been marked, and is about to be reclaimed.
 
262
Then call <TT>GC_is_marked(p)</tt> from the debugger to verify that the
 
263
object has not been marked, and is about to be reclaimed.  Note that
 
264
<TT>GC_is_marked(p)</tt> expects the real address of an object (the
 
265
address of the debug header if there is one), and thus it may
 
266
be more appropriate to call <TT>GC_is_marked(GC_base(p))</tt>
 
267
instead.
253
268
<LI> Determine a path from a root, i.e. static variable, stack, or
254
269
register variable,
255
270
to the reclaimed object.  Call <TT>GC_is_marked(q)</tt> for each object