Bug #19674 sp-threads.test can crash in stress test

Description:
This is probably not (easily) repeatable, but the right developer might be able to fix it anyway. The cause is quite clear. So it should be easy to fix.

I say it is not (easily) repeatable, because it happend when running a stress test. I tried this a couple of times and it crashed (or locked up) at different places each time...

The forensics, as far as I did them, show:

The stack backtrace:

(gdb) bt
#0  0xb7f569d3 in pthread_kill () from /lib/tls/libpthread.so.0
#1  0x08376689 in write_core (sig=11) at stacktrace.c:220
#2  0x0820eba2 in handle_segfault (sig=11) at mysqld.cc:2099
#3  <signal handler called>
#4  0x08230308 in check_table_access (thd=0x8fcd2d8, want_access=8, tables=0x902f598, no_errors=false) at sql_parse.cc:5215
#5  0x08234245 in multi_delete_precheck (thd=0x8fcd2d8, tables=0x902f758) at sql_parse.cc:7040
#6  0x0822aa2c in mysql_execute_command (thd=0x8fcd2d8) at sql_parse.cc:3407
#7  0x08390f5f in sp_instr_stmt::exec_core (this=0x902fcd8, thd=0x8fcd2d8, nextp=0xb26a68d0) at sp_head.cc:2308
#8  0x08390ba0 in sp_lex_keeper::reset_lex_and_exec_core (this=0x902fd00, thd=0x8fcd2d8, nextp=0xb26a68d0, open_tables=false, instr=0x902fcd8) at sp_head.cc:2187
#9  0x08390de7 in sp_instr_stmt::execute (this=0x902fcd8, thd=0x8fcd2d8, nextp=0xb26a68d0) at sp_head.cc:2261
#10 0x0838d9e1 in sp_head::execute (this=0x902f288, thd=0x8fcd2d8) at sp_head.cc:1060
#11 0x0838ecb3 in sp_head::execute_procedure (this=0x902f288, thd=0x8fcd2d8, args=0x8fcd7ac) at sp_head.cc:1500
#12 0x0822dd90 in mysql_execute_command (thd=0x8fcd2d8) at sql_parse.cc:4432
#13 0x082315df in mysql_parse (thd=0x8fcd2d8, inBuf=0x90020e8 "call bug11158()", length=15) at sql_parse.cc:5704
#14 0x0822641f in dispatch_command (command=COM_QUERY, thd=0x8fcd2d8, packet=0x8fe7b71 "call bug11158()", packet_length=16) at sql_parse.cc:1745
#15 0x08225b58 in do_command (thd=0x8fcd2d8) at sql_parse.cc:1531
#16 0x08224bbd in handle_one_connection (arg=0x8fcd2d8) at sql_parse.cc:1174
#17 0xb7f53ced in start_thread () from /lib/tls/libpthread.so.0
#18 0xb7e7cdee in clone () from /lib/tls/libc.so.6
(gdb) 

You can see that the statement is "call bug11158()", which occurs in sp-threads.test only. Perhaps running this test case alone in a stress test might trigger the problem again.

In check_table_access() at sql_parse.cc:5215 the crashing statement is this:

5215     if (tables->derived || tables->schema_table || tables->belong_to_view ||
5216         (tables->table && (int)tables->table->s->tmp_table) ||
5217         my_tz_check_n_skip_implicit_tables(&tables,
5218                                            thd->lex->time_zone_tables_used))
5219       continue;

Here, the contents of tables->table is 0x8f8f8f8f at all places. Hence, tables->table has been freed without setting tables->table= NULL. I think a developer experienced in stored procedures should be able to find the place where this omission happened.

How to repeat:
BUILD/compile-pentium-debug-max
cd mysql-test
./mysql-test-run --stress --stress-threads=3

Suggested fix:
Set tables->table= NULL when tables->table is freed.

When I run ./mysql-test-run --stress --stress-threads=3 (with sp-threads only in stress_tests.txt on today's 5.0.22-BK, I've got (never ending) list S3 errors, but not crash. Although, it was NOT a debug build.

In var/stress/20060510121554/mysql-stress-test.log I've got:

TestID TID      Suite         TestFileName Found Errors
=======================================================
     1   1       main      sp-threads.test Severity S3: 1

S3: Count:1 Error:1304: PROCEDURE bug4934 already exists

     2   2       main      sp-threads.test Severity S3: 1

S3: Count:1 Error:1304: PROCEDURE bug4934 already exists

     3   1       main      sp-threads.test Severity S3: 1

S3: Count:1 Error:1146: Table 'test.t1' doesn't exist

     5   2       main      sp-threads.test Severity S3: 1

S3: Count:1 Error:1146: Table 'test.t1' doesn't exist

     7   2       main      sp-threads.test Severity S3: 1

S3: Count:1 Error:1304: PROCEDURE bug4934 already exists
...

Strings 5215 - 5219 in sql_parse.cc now are different as you showed. And I can not repeat this bug usin current BK sources.

Please, check with current BK sources and if you still catch the problem, please, provide content of your stress_tests.txt file.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".