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]> > 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
