MDN may have intermittent access issues April 18 13:00 - April 19 01:00 UTC. See whistlepig.mozilla.org for all notifications.

mozilla

Compare Revisions

Debugging Mozilla with gdb

Change Revisions

Revision 68159:

Revision 68159 by Fantasai on

Revision 489865:

Revision 489865 by luke@mozilla.com on

Title:
Debugging Mozilla with gdb
Debugging Mozilla with gdb
Slug:
Debugging_Mozilla_with_gdb
Debugging_Mozilla_with_gdb
Content:

Revision 68159
Revision 489865
n13    <h3 id="Where_can_I&nbsp;find_general_gdb_documentation?">n13    <h3 id="Where_can_I.C2.A0find_general_gdb_documentation.3F">
n47(gdb) <strong>set args <a class=" external" href="http://www.mozin47(gdb) <strong>set args <a class="external" href="http://www.mozil
>lla.org" rel="freelink">http://www.mozilla.org</a></strong>>la.org" rel="freelink">http://www.mozilla.org</a></strong>
n70    <h3 id="I_can't_set_a_breakpoint._Why_not?">n70    <h3 id="I_can't_set_a_breakpoint._Why_not.3F">
n81    </p>n
82    <p>
83      The easiest way to read a PRUnichar* is like so:
84    </p>
85    <pre>
86(gdb) x/hs unicharPtr
87</pre>
88    <p>
89      Just remember to replace "unicharPtr" with the name of the 
>PRUnichar* variable name. 
nn87    <dl>
88      <dd>
89        &nbsp;
90      </dd>
91    </dl>
n179      You can call the ToNewCString() method on the nsString in qn175      You can call the ToNewCString() method on the nsString in q
>uestion. It leaks a little memory but it shouldn't hurt anything >uestion. It leaks a little memory but it shouldn't hurt anything 
>if you only do it a few times in one gdb session. ( from <a class>if you only do it a few times in one gdb session. ( from <a class
>=" link-mailto" href="mailto:akkana@netscape.com" rel="freelink">>="link-mailto" href="mailto:akkana@netscape.com" rel="freelink">a
>akkana@netscape.com</a> )>kkana@netscape.com</a> )
n252    <h3 id="How_do_I_run_the_debugger_in_emacs/xemacs?">n248    <h3 id="How_do_I_run_the_debugger_in_emacs.2Fxemacs.3F">
n272    <h3 id="gdb_5_used_to_work_for_me,_but_now_Mozilla_won't_starn268    <h3 id="gdb_5_used_to_work_for_me.2C_but_now_Mozilla_won't_st
>t._What_can_I_do?">>art._What_can_I_do.3F">
n276      A recent threading change (see <a class="external" href="htn272      A recent threading change (see <a class="external" href="ht
>tp://bugzilla.mozilla.org/show_bug.cgi?id=57051">bug 57051</a> fo>tp://bugzilla.mozilla.org/show_bug.cgi?id=57051">bug 57051</a> fo
>r details) caused a problem on some systems: Mozilla would get pa>r details) caused a problem on some systems: Mozilla would get pa
>rtway through its initialization, then die before showing a windo>rtway through its initialization, then die before showing a windo
>w. A recent change to gdb has fixed this problem. Download and bu>w. A recent change to gdb has fixed this problem. Download and bu
>ild [ <a class=" external" href="http://sources.redhat.com/insigh>ild [ <a class="external" href="http://sources.redhat.com/insight
>t/" rel="freelink">http://sources.redhat.com/insight/</a> the lat>/" rel="freelink">http://sources.redhat.com/insight/</a> the late
>est version of Insight], or if you don't want a GUI, <a class="ex>st version of Insight], or if you don't want a GUI, <a class="ext
>ternal" href="http://sources.redhat.com/gdb/">the latest version >ernal" href="http://sources.redhat.com/gdb/">the latest version o
>of gdb</a>.>f gdb</a>.
nn307    <h3 name="I_keep_getting_a_SIG32_in_the_debugger._How_do_I_fi
 >x_it.3F">
308      I keep getting a SIGSEGV in JS/JIT code under gdb even thou
 >gh there is no crash when gdb is not attached.&nbsp; How do I fix
 > it?
309    </h3>
310    <p>
311      tl;dr: starting in FF28, set the JS_DISABLE_SLOW_SCRIPT_SIG
 >NALS environment variable.
312    </p>
313    <p>
314      If JS runs to long, the browser needs to throw up the "Slow
 > Script Dialog" to allow the user to stop runaway execution.&nbsp
 >; Normally, this requires testing some atomic variable, set by a 
 >watchdog thread, on every loop backedge, function prologue, etc.&
 >nbsp; This has a runtime cost.&nbsp; To avoid this cost for hot J
 >IT code, the JS engine uses a clever hack: when the script has po
 >tentially run for too long, the watchdog thread changes the memor
 >y protection bits of the JIT code so that execution immediately h
 >alts with a fault.&nbsp; When the fault occurs, a JS-installed fa
 >ult-handler function is run which recovers gracefully and allows 
 >the user to abort execution.&nbsp; Unfortunately, gdb doesn't kno
 >w intermediate fault is innocuous so it breaks in the same way as
 > a real crash.&nbsp; If you 'continue', then execution will proce
 >ed (into the handler, which recovers gracefully), but this is ann
 >oying and it can happen many times in a row.
315    </p>
316    <p class="bz_comment_text" id="comment_text_12">
317      The fix is to set a new environment variable (added in Fire
 >fox 28): JS_DISABLE_SLOW_SCRIPT_SIGNALS.&nbsp; When this enviornm
 >ent variable is set, the JS engine makes no attempt to interrupt 
 >Ion/Odin JIT code.&nbsp; (JS code running in the baseline JIT or 
 >interpreter will be interrupted just fine.)&nbsp; This means that
 > an iloop in Ion/Odin will not be interruptible so this environme
 >nt variable should only be used when debugging.
318    </p>
n375    <h3 id="&nbsp;See_also">n383    <h3 id=".C2.A0See_also">
n392        <a class="external" href="http://hg.mozilla.org/users/josn400        <a class="external" href="http://hg.mozilla.org/users/jos
>h_joshmatthews.net/archer-mozilla/" title="http://hg.mozilla.org/>h_joshmatthews.net/archer-mozilla/" title="http://hg.mozilla.org/
>users/josh_joshmatthews.net/archer-mozilla/">More pretty printers>users/josh_joshmatthews.net/archer-mozilla/">More pretty printers
></a> for Gecko internals (<a class="external" href="http://www.jo></a> for Gecko internals (<a class="external" href="http://www.jo
>shmatthews.net/blog/2011/06/nscomptr-has-never-been-so-pretty/" t>shmatthews.net/blog/2011/06/nscomptr-has-never-been-so-pretty/" t
>itle="http://www.joshmatthews.net/blog/2011/06/nscomptr-has-never>itle="http://www.joshmatthews.net/blog/2011/06/nscomptr-has-never
>-been-so-pretty/">blog post</a>)<a href="/blog/2011/06/nscomptr-h>-been-so-pretty/">blog post</a>)
>as-never-been-so-pretty" title="blog/2011/06/nscomptr-has-never-b 
>een-so-pretty/"><br></a> 
tt415    <p>
416      &nbsp;
417    </p>

Back to History