Documentation Source Text

to understand, it is often useful to run it in the [command-line shell]
with the ".eqp full" setting.  When ".eqp" is set to FULL, the shell
automatically shows the [EXPLAIN] and [EXPLAIN QUERY PLAN] output for
each command prior to actually running that command.

<p>For added readability, also set ".echo on" so that the output contains
the original SQL text.



</li>

<li>
<p><b>Use compile-time options to enable debugging features.</b>

<p>Suggested compile-time options include:
<ul>
................................................................................

<p>When debugging the [bytecode] generator, it is often useful to know
where a particular opcode is being generated.  To find this easily,
run the script in a debugger.  Set a breakpoint on the "test_addoptrace"
routine.  Then run the "PRAGMA vdbe_addoptrace=ON;" followed by the
SQL statement in question.  Each opcode will be displayed as it is
appended to the VDBE program, and the breakpoint will fire immediately
thereafter.  Step until reaching the opcode and question then look backwards
in the stack to see where and how it was generated.

<p>This only works when compiled with [SQLITE_DEBUG].
</li>

<li>
<p><b>Using the ".selecttrace" and ".wheretrace" shell commands</b>
................................................................................
</li>

<li>
<p><b>Disable the [lookaside memory allocator]</b>

<p>When looking for memory allocation problems (memory leaks, use-after-free
errors, buffer overflows, etc) it is sometimes useful to disable the
[lookaside memory allocator] then run the test under valgrind.

The lookaside memory allocator can 
be disabled at start-time using the [SQLITE_CONFIG_LOOKASIDE]
interface.  The [command-line shell] will use that interface to
disable lookaside if it is started with the "--lookaside 0 0"
command line option.
</li>
</ol>

to understand, it is often useful to run it in the [command-line shell]
with the ".eqp full" setting.  When ".eqp" is set to FULL, the shell
automatically shows the [EXPLAIN] and [EXPLAIN QUERY PLAN] output for
each command prior to actually running that command.

<p>For added readability, also set ".echo on" so that the output contains
the original SQL text.

<p>The newer ".eqp trace" command does everything that ".eqp full" does
and also turns on [vdbe_trace|VDBE tracing].
</li>

<li>
<p><b>Use compile-time options to enable debugging features.</b>

<p>Suggested compile-time options include:
<ul>
................................................................................

<p>When debugging the [bytecode] generator, it is often useful to know
where a particular opcode is being generated.  To find this easily,
run the script in a debugger.  Set a breakpoint on the "test_addoptrace"
routine.  Then run the "PRAGMA vdbe_addoptrace=ON;" followed by the
SQL statement in question.  Each opcode will be displayed as it is
appended to the VDBE program, and the breakpoint will fire immediately
thereafter.  Step until reaching the opcode then look backwards
in the stack to see where and how it was generated.

<p>This only works when compiled with [SQLITE_DEBUG].
</li>

<li>
<p><b>Using the ".selecttrace" and ".wheretrace" shell commands</b>
................................................................................
</li>

<li>
<p><b>Disable the [lookaside memory allocator]</b>

<p>When looking for memory allocation problems (memory leaks, use-after-free
errors, buffer overflows, etc) it is sometimes useful to disable the
[lookaside memory allocator] then run the test under valgrind or MSAN or
some other heap memory debugging tool.
The lookaside memory allocator can 
be disabled at start-time using the [SQLITE_CONFIG_LOOKASIDE]
interface.  The [command-line shell] will use that interface to
disable lookaside if it is started with the "--lookaside 0 0"
command line option.
</li>
</ol>