I’ve been working with a client recently who has SELinux on his servers.  It has been quite a struggle sometimes.

My colleages tell me that SELinux has a pretty noticeable performance impact.  I am not sure if we have benchmarks to support this; at any rate, the client said it’s OK, we’ll take the performance hit.

There [...]

We use valgrind to find memory leaks in MySQL on Linux. The tool is a convenient, and often enlightening way of finding out where the real and potential problems are location.

On Windows, you dont have valgrind, but Microsoft do provide a free native debugging tool, called the user-mode dump heap (UMDH) tool. This performs a similar function to valgrind to determine memory leaks.

Vladislav Vaintroub, who works on the Falcon team and is one of our resident Windows experts provides the following how-to for using UMDH:

1. Download and install debugging tools for Windows from here
   MS Debugging Tools
   Install 64 bit version if you’re on 64 bit Windows and 32 bit version
   otherwise.

2. …

In almost all application development situations, one needs to log debug information now and then. In almost all production systems, one needs to log serious error events somewhere too.

So, what can you do? Create a log table? Sprinkle your code with SELECT 'Debug: ...' statements?

At the UDF Repository for MySQL, we now have a solution to log messages to the MySQL error log: a user-defined function called log_error().

Currently it is all very crude: the log_error function takes one argument and writes it to the mysql_error log, appending a line …

One basic way of debugging the MySQL Cluster data nodes(ndbd) is with good old printf-style debugging. Ie. adding printouts of the variable you want to see, recompile, start the node(s) and run your tests. This is a bit tedious but very universal.

Support for printing is available using "ndbout", which has both C++ style and printf style. This functionality is implemented in storage/ndb/include/util/NdbOut.hpp

Here is an example from debugging BUG#37592, where I wanted to add printouts to "Dbtup::rebuild_page_free_list" to see how the pageId increases while the rebuild is running:

void
Dbtup::rebuild_page_free_list(Signal* signal)
{
  Ptr fragOpPtr;
  fragOpPtr.i = signal->theData[1];
  Uint32 pageId = signal->theData[2];
  Uint32 tail = signal->theData[3];
  ptrCheckGuard(fragOpPtr, …

Not sure if the post title actually reflects the contents. 

This post describes how you can obtain the traces that MySQL server leaves behind for you if you ask it to. Once you have the traces, you can use it for:

• Debugging - It can help you to find out which source file is the server crashing, for eg.
• Learn- learn more about which functions/methods are called for a particular query by the client

Okay, so lets start.

Traceable Server

To be able to obtain traces, your server needs to be compiled with "debug" enabled. If the version information shows you something like this:

Ver 5.1.24-rc-debug for pc-linux-gnu on i686 (Source distribution)

with 'debug' appended to the version name, then you have a traceable server, else you will have to recompile it by enabling debug support:

./configure …

Not sure if the post title actually reflects the contents. 

This post describes how you can obtain the traces that MySQL server leaves behind for you if you ask it to. Once you have the traces, you can use it for:

• Debugging - It can help you to find out which source file is the server crashing, for eg.
• Learn- learn more about which functions/methods are called for a particular query by the client

Okay, so lets start.

Traceable Server

To be able to obtain traces, your server needs to be compiled with "debug" enabled. If the version information shows you something like this:

Ver 5.1.24-rc-debug for pc-linux-gnu on i686 (Source distribution)

with 'debug' appended to the version name, then you have a traceable server, else you will have to recompile it by enabling debug support:

./configure …

After seeing strange crashes in xmlFreeTextWriter() on only one platform oldag and me dove into wonders of shared linking.

<oldag> just sit right back, and you'll hear a tale
<oldag> a tale of a faitful trip
<oldag> if not for the courage of the fearless crew (oldag and jan), the Minnow would be lost!
<eric> :)
<oldag> so, who LOVES unix shared lib dynamic linking!
<eric> you know you can sing that to the tune of "Amazing Grace" ?
<oldag> who loves it!
<oldag> come on....
* eric jumps up and down
<eric> Me!
<eric> Me!
<eric> Me!
<eric> not really.
<oldag> so get this
<eric> mmm, hmm?
<oldag> my xml "writer" was being alloc'd by one xml lib
<oldag> and then trying to be freed by another
<oldag> and they disagreed on size
<mark> With different sized structs :P

One libxml was the system libxml in Mac OS X 10.5 (2.6.22), the other one from MacPorts …

Let's see if you can solve this little puzzle...

Consider this stored procedure:

-- finds the first slash and exits
create procedure p_find_slash(p_text text)
begin
    declare v_index int default 1;
    declare v_length int default character_length(p_text);
    declare v_char char(1);
    
    _main_loop: while v_index <= v_length do                       -- loop over all characters
                
        set v_char := substring(p_text, v_index, 1);               -- grab the current character
        case v_char
            when v_char = '/' then                                 -- found a slash!                
                select concat('A slash at ', v_index) message;     -- report it
                leave _main_loop;                                  -- and then stop
            else …

Yesterday I starting testing PBXT using the DBT2 benchmark. Following the implementation of durability and SELECT FOR UPDATE for the engine I was more interested in the benchmark as a test for stability and concurrency than performance. I was not disappointed...

Which bug first?

Well I immediately ran into 3 bugs. Isn't it funny how bugs often come in batches, which leaves you thinking: "Oh sh.. where do I start?". Here's my advice: start with the bug that is most likely to disappear if you fix the others!

A simple example, you have 2 bugs: an unexpected exception is occurring, and you're loosing memory. First look for the memory loss, because it may disappear when you fix the exception (because you may be loosing memory in the error handler).

Take things one problem at time:

Another thing: once you have decided for one of the bugs, stick with it (no matter how hard it gets) …

Lua is a great programming language and I use it as embedded scripting language in

• MySQL Proxy
• wormhole Storage Engine
• lighttpd

What impresses me most it's flexibility. What ever I come up with is only a few lines away ... and I have crazy ideas. Like profiling lua scripts with KCacheGrind.

For profiling lua-scripts you can use

• luaprofiler
• …