DBUG_ASSERT purpose

[Ezameku]

Hello everyone,

I’m actually debugging query cache in MySQL (and Percona Server) because I’m actually encountering many errors in the query cache part.

The source code (sql/sql_cache.cc) is full of DBUG_ASSERT.
In production, the code seems to run smoothly, but when in debug mode, MySQL can’t stop exiting (SIGABRT) at many DBUG_ASSERT because they don’t match …

I wondered how DBUG_ASSERT was used by MySQL core developers :

• is this really a help to debug, and a DBUG_ASSERT must never fail ?
• or was it used to spare some “if () return;” in the source code ?

On example I’m looking at is this revision :
http://bazaar.launchpad.net/~mysql/mysql-server/mysql-5.1/re vision/2728.6.1

I don’t want to create bug report on MySQL if this is an “attended behavior”, and I was unable to find good documentation on MySQL coding guidelines, or any article on DBUG_ASSERT.

I hope there are some MySQL gurus out there who can help me out.

Thank you !

[sterin]

I can’t answer for MySQL coding guidelines per se, but asserts are definitely a tool for developers.
Ezameku wrote on Thu, 25 August 2011 10:56

I wondered how DBUG_ASSERT was used by MySQL core developers :

• is this really a help to debug, and a DBUG_ASSERT must never fail ?
• or was it used to spare some “if () return;” in the source code ?

An assert is used as a fast internal check that the assumptions that your code are making is valid. Eg to check that an internal function that performs a special modification of an object isn’t called with a null referens to an object.

“if() return” or “if () throw” are used check input when the input can change due to outside factors. Eg a public function that validates input from a user, where the input data can change during runtime.

Ezameku wrote on Thu, 25 August 2011 10:56

I don’t want to create bug report on MySQL if this is an “attended behavior”, and I was unable to find good documentation on MySQL coding guidelines, or any article on DBUG_ASSERT.

Asserts should never fail, either you have something odd in your test environment (mismatching versions of code compiled together?) that causes them to fire, or the code is more or less under development, or the asserts has not been maintained as the code has evolved.

So if you can rule out anything odd in your test environment then IMHO I think you should issue a bug report (at least to get possible faulty asserts out of the code).