Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
-
None
Description
#3 <signal handler called>
|
#4 0x000000000069df0d in Index_statistics::set_avg_frequency (this=0x7f80300197f0, i=0, val=1) at 10.0-base/sql/sql_statistics.h:242
|
#5 0x000000000069f7a2 in Index_stat::get_stat_values (this=0x7f803ef96560) at 10.0-base/sql/sql_statistics.cc:1225
|
#6 0x000000000069c2fc in read_statistics_for_table (thd=0x3c3c1f0, table=0x7f8034001200, stat_tables=0x7f803ef967c0) at 10.0-base/sql/sql_statistics.cc:2393
|
#7 0x000000000069ca73 in read_statistics_for_tables_if_needed (thd=0x3c3c1f0, tables=0x3b8e6f8) at 10.0-base/sql/sql_statistics.cc:2570
|
#8 0x00000000005b3081 in open_and_lock_tables (thd=0x3c3c1f0, tables=0x3b8e6f8, derived=true, flags=0, prelocking_strategy=0x7f803ef97a60) at 10.0-base/sql/sql_base.cc:5613
|
#9 0x00000000005a6491 in open_and_lock_tables (thd=0x3c3c1f0, tables=0x3b8e6f8, derived=true, flags=0) at 10.0-base/sql/sql_base.h:501
|
#10 0x00000000005ee269 in mysql_insert (thd=0x3c3c1f0, table_list=0x3b8e6f8, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=false) at 10.0-base/sql/sql_insert.cc:729
|
#11 0x000000000060e457 in mysql_execute_command (thd=0x3c3c1f0) at 10.0-base/sql/sql_parse.cc:3054
|
#12 0x000000000061650f in mysql_parse (thd=0x3c3c1f0, rawbuf=0x3b8e578 "INSERT INTO `table0_myisam` ( `col_float_not_null_key` ) VALUES ( RAND () )", length=75, parser_state=0x7f803ef98550) at 10.0-base/sql/sql_parse.cc:5874
|
#13 0x00000000006096cb in dispatch_command (command=COM_QUERY, thd=0x3c3c1f0, packet=0x3c42231 "INSERT INTO `table0_myisam` ( `col_float_not_null_key` ) VALUES ( RAND () )", packet_length=75) at 10.0-base/sql/sql_parse.cc:1072
|
#14 0x0000000000608982 in do_command (thd=0x3c3c1f0) at 10.0-base/sql/sql_parse.cc:811
|
#15 0x0000000000716f47 in do_handle_one_connection (thd_arg=0x3c3c1f0) at 10.0-base/sql/sql_connect.cc:1253
|
#16 0x0000000000716932 in handle_one_connection (arg=0x3c3c1f0) at 10.0-base/sql/sql_connect.cc:1168
|
#17 0x00007f8059d7cefc in start_thread (arg=0x7f803ef99700) at pthread_create.c:304
|
#18 0x00007f80590eef4d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0x3b8e578): INSERT INTO `table0_myisam` ( `col_float_not_null_key` ) VALUES ( RAND () )
|
Connection ID (thread ID): 8
|
Status: NOT_KILLED
|
revision-id: igor@askmonty.org-20121220233829-rcbryu0uy5z5kdz1
|
date: 2012-12-20 15:38:29 -0800
|
revno: 3457
|
branch: 10.0-base
|
Built with BUILD/compile-pentium-debug-max-no-ndb
randgen revno 792
|
Steps to reproduce
Start server on a clean datadir as
mysqld --no-defaults --disable-debug <--basedir, --datadir etc.>
|
Branch or pull bzr tree lp:randgen
cd randgen
Download files mdev-3972.yy and mdev-3972.zz attached to the bug MDEV-3972 to the root of randgen folder
Run
perl ./gentest.pl --gendata=mdev-3972.zz --threads=8 --queries=100M --duration=3600 --dsn=dbi:mysql:host=127.0.0.1:port=3306:user=root:database=test --grammar=mdev-3972.yy
|
Notes:
Important: Do not forget to replace 3306 in gentest dsn option with your server's port if you run it on a different one.
Important: I could NOT reproduce the crash when I built with BUILD/compile-pentium-valgrind-max-no-ndb, although I didn't keep trying for very long. With BUILD/compile-pentium-debug-max-no-ndb it was reproducible well enough.
Important: the server option disable-debug was critical, at least on my machine: I could never reproduce the crash if I skipped the option. Please use it at least at the beginning, you can experiment later after you make sure it's reproducible this way.
I ran the test using this exact algorithm, data and grammar files, 6 times in a row, to collect some statistics. 4 times it crashed with the stack trace described here, and 2 times it was MDEV-3983, but it did crash every time. It took from 3 to 20 minutes, but please allow it to run the full hour (as given in the test parameters) before giving up. I suppose you can also get other crashes from recently filed bugs. I don't know whether it means that they have the same root cause, or they are entirely different and just happen to be triggered by the same stress test.
The test as configured above runs with 8 connections. Functionally, it's excessive, on a Windows machine I was able to get the crash with 4 connections. But on my Ubuntu installation, it required more. If you are getting the crash fast enough, you can try to reduce the number in the threads parameter, if it helps to debug.
If you start the test again after crash, it's better to re-create the datadir. I've seen cases when stat tables were reported corrupted after a crash, and the server would crash again almost immediately, I suppose it can be misleading for debugging the underlying problem.
I could not reproduce the problem on a slow 32-bit machine. I'm not sure whether it's because it's 32-bit or because it's slow, but please keep it in mind.
Attachments
Issue Links
- relates to
-
-
- Closed
-