FYI, I have a detailed discussion on GDB and Drizzle here:
http://drizzle.org/wiki/Debugging_Drizzle_with_GDB
Cheers,
Jay
Philip Herron wrote:
Hey
Whoo Thats is like explained my question completly! I have been debuging
with just statements everywhere because i doing the configure option
with debugging on. But you have given me great detail! I think i need to
learn to use GDB still never used it yet. But no time like the present!
Ordered the GDB pocket reference now! :) Always wanted to learn it
because i have a small personal project on a small kernel and i know you
can attach gdb to qemu so yeah..
Thanks hopefuly have some code cleanup pacthes soon... When i get them
workings properly
-Phil
http://redbrain.co.uk
2009/1/11 Jay Pipes <[email protected] <mailto:[email protected]>>
Philip Herron wrote:
Hey guys
Just wondering, i have been messing with the code for a while
this past 3 days and i was wondering on a good way to make sure
any modifications are tested properly, like myself first before
i send in any patches i make.
I see there are a few binaries to run, but not quite sure the
best way to test! Like what should be done to set up the
database then to run some tests to make sure the code is stable :).
Hi Philip! Well, with the current testing system, here is a quick
way to test your code, but only if it touches stuff that relates to
SQL specifically (meaning, for right now, it doesn't touch
replication or stuff that occurs *before* client connection threads
hit the mysql_parse() routine in sql_parse.cc)
1) Before you begin your modifications, create a test case which
will demonstrate the change in behaviour you look to implement.
To do so, simply create a file called xxx.test. xxx should be some
descriptive name of what you are working on (like a bug number or a
small feature or patch).
2) Place the file in the tests/t/ directory.
3) In the test file, place commands which demonstrate the behaviour
you wish to modify. Commands are simply SQL commands or a variety
of mysqltest commands. The important ones to know for right now are
these:
--error XXXX
Place the above *directly before* a SQL command which you expect to
throw an error number XXXX
--disable_warnings/--enable_warnings
Place this as a block around code you don't want to track warnings
on. Typically, this would be around a command such as:
DROP TABLE IF EXISTS t1;
since that will throw a warning if t1 does not exist.
Feel free, of course, to peruse the existing test cases to see
examples of how a test case is laid out. Stick to the simple stuff
first, and don't go down the rabbit-hole of trying to understand all
the test-specific commands. Just stick to the basic SQL commands at
first.
4) Make your code modifications.
5) Compile and build Drizzle:
$> ./config/autorun.sh && ./configure --with-debug && make -j2
(you can replace make -j2 with the concurrency level of your choice
of course...usually I set it to the number of cores in the compiling
machine)
You will want to configure --with-debug so that you can do code
investigation easily with GDB.
6) Run your test.
$> cd tests
$> ./dtr xxx
Where xxx is the name of the test case you created in step 1)
7) If the test runs successfully, you will see the output of the
test commands along with a message saying something like "results
file not found". This is fine for now. If the test case bombed,
you will know, since it will show the error failure. If it fails, go
to step 11.
8) Go ahead and double-check that the results of the SQL commands in
your test case were appropriate and correct. *Be very thorough about
this process!*
9) Once you are sure that the test case produces correct results,
you need to record a results file:
(from the tests/ directory again)
$> ./dtr --record xxx
where xxx is the name of your test case
This will produce a test case results file corresponding to your
test case run and save that file in tests/r/xxx.result.
You can verify a passing test case by running the test case again,
without the --record option. You should see a passing test case
printout.
10) Now, any time you make changes, simply compile Drizzle and run
your test case again to verify no regressions.
11) When you encounter failures, it is often valuable to figure out
what is going on via GDB. This is critical if you get an error
saying "Lost connection to Drizzle during query", as this typically
means a segfault occurred on the server and you need to track it
down. Follow steps 12-14 to debug Drizzle in GDB.
12) Run your test case with the server in GDB:
$> cd tests
$> ./dtr --gdb xxx
Where xxx is your test case's name
An xterm window will open up with the Drizzle server at the
mysql_parse() function breakpoint, automatically set by the test
runner. I won't go into a full tutorial of how to use GDB (Google
exists, after all) but here is a quick set of things to do:
When in the GDB console:
where<Enter>
will produce the current call stack where you have currently
"broken" at. This is very useful if you run into a segfault and
need to know the backtrace up to where you have received a fault.
step<Enter>
Steps into the next instruction and shows the instruction to you.
This will step "into" each function as you hit it.
list<Enter>
Shows the block of source code you are currently in.
next<Enter>
Jump to the next instruction. This will step "through" a function
call, not into it.
continue<Enter>
Just fires the code through to a segfault or a clean exit.
print xxx<Enter>
Prints the value of the variable xxx (Note, no semicolon before <Enter>)
OK, that's it for now...
Have fun :)
Cheers,
Jay
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
