crash with 4.0.9 on linux
crash with 4.0.9 on linux
am 20.01.2003 16:47:44 von mmokrejs
Hi,
I've just observerd the following:
How-To-Repeat:
0x806f3bb handle_segfault + 447
0x8269ab8 pthread_sighandler + 184
0x82955b3 memcpy + 51
0x82312f0 _mi_pack_get_block_info + 316
0x8230171 _mi_read_pack_record + 53
0x8229b08 mi_rkey + 520
0x80c331f index_read_idx__9ha_myisamPcUiPCcUi16ha_rkey_function + 59
0x809ad32 join_read_const__FP13st_join_table + 102
0x809ab29 join_read_const_table__FP13st_join_tableP11st_position + 85
0x809381e make_join_statistics__FP4JOINP13st_table_listP4ItemP16st_dyn amic_array + 2106
0x8091be3 mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st _orderT4T3T4UlP13select_result + 2003
0x80913d6 handle_select__FP3THDP6st_lexP13select_result + 102
0x807942a mysql_execute_command__Fv + 950
0x807ce26 mysql_parse__FP3THDPcUi + 146
0x807853b dispatch_command__F19enum_server_commandP3THDPcUi + 1475
0x8077f6d do_command__FP3THD + 149
0x80777af handle_one_connection + 635
0x826726c pthread_start_thread + 220
0x829c80a thread_start + 4
The crash was supposedly caused by:
thd->query at 0x84c2598 = select dat from blast_data where id='938'
thd->thread_id=3
I've retried to issue same sql command manully, but it seems to work.
So, this happens probably under certain conditions.
--
Martin Mokrejs ,
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13529@lists.mysql.com
To unsubscribe, e-mail
Re: crash with 4.0.9 on linux
am 20.01.2003 18:10:19 von Sinisa Milivojevic
=3D?iso-8859-2?Q?Martin_MOKREJ=3DA9?=3D writes:
> Hi,
> I've just observerd the following:
>=20
> How-To-Repeat:
>=20
> 0x806f3bb handle_segfault + 447
> 0x8269ab8 pthread_sighandler + 184
> 0x82955b3 memcpy + 51
> 0x82312f0 _mi_pack_get_block_info + 316
> 0x8230171 _mi_read_pack_record + 53
> 0x8229b08 mi_rkey + 520
> 0x80c331f index_read_idx__9ha_myisamPcUiPCcUi16ha_rkey_function + 59
> 0x809ad32 join_read_const__FP13st_join_table + 102
> 0x809ab29 join_read_const_table__FP13st_join_tableP11st_position + 85=
> 0x809381e make_join_statistics__FP4JOINP13st_table_listP4ItemP16st_dy=
namic_array + 2106
> 0x8091be3 mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8s=
t_orderT4T3T4UlP13select_result + 2003
> 0x80913d6 handle_select__FP3THDP6st_lexP13select_result + 102
> 0x807942a mysql_execute_command__Fv + 950
> 0x807ce26 mysql_parse__FP3THDPcUi + 146
> 0x807853b dispatch_command__F19enum_server_commandP3THDPcUi + 1475
> 0x8077f6d do_command__FP3THD + 149
> 0x80777af handle_one_connection + 635
> 0x826726c pthread_start_thread + 220
> 0x829c80a thread_start + 4
>=20
>=20
> The crash was supposedly caused by:
>=20
> thd->query at 0x84c2598 =3D select dat from blast_data where id=3D'93=
8'
> thd->thread_id=3D3
>=20
> I've retried to issue same sql command manully, but it seems to wor=
k.
> So, this happens probably under certain conditions.
> --=20
> Martin Mokrejs ,
> PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
> MIPS / Institute for Bioinformatics
> GSF - National Research Center for Environment and Health
> Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
> tel.: +49-89-3187 3683 , fax:=A0+49-89-3187 3585
Hi!
If you could specify those conditions, we would be gratefull.=20
We do require a repeatable test case.
--=20
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ www.mysql.com
Join MySQL Users Conference and Expo:
http://www.mysql.com/events/uc2003/
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13530@lists.mysql.com
To unsubscribe, e-mail
Re: crash with 4.0.9 on linux
am 29.01.2003 20:35:52 von mmokrejs
On Wed, 29 Jan 2003, Peter Zaitsev wrote:
Hi,
I've managed to reproduce this once. I've a script doing slect on every
database on same table. Two such tables are broken (I've no clue if this
is really needed).
Info: Using database Clostridium_acetobutylicum_ATCC824 at @xx:3306
[@xx:3306 Clostridium_acetobutylicum_ATCC824.contig_data]: 0 0 Clostridium_acetobutylicum_ATCC824
Info: Using database Clostridium_botulinum_A at @xx:3306
[@xx:3306 Clostridium_botulinum_A.contig_data]: 0 0 contig1
Info: Using database Clostridium_difficile_630 at @xx:3306
[@xx:3306 Clostridium_difficile_630.contig_data]: 0 0 contig710.0.0
Info: Using database Clostridium_perfringens_13 at @xx:3306
[@xx:3306 Clostridium_perfringens_13.contig_data]: 0 0 NC_003042
Info: Using database Clostridium_thermocellum_ATCC27405 at @xx:3306
Error: [@xx:3306 Clostridium_thermocellum_ATCC27405.contig_data]: (execute failed): Lost connection to MySQL server during query
Error: [@xx:3306 Corynebacterium_diphteriae_NCTC_13129]: Can't connect to MySQL server on 'xx' (111)
Error: Cannot use database Corynebacterium_diphteriae_NCTC_13129 on xx:3306. Skipping.
Error: [@xx:3306 Corynebacterium_efficiens_YS314T]: Can't connect to MySQL server on 'xx' (111)
Error: Cannot use database Corynebacterium_efficiens_YS314T on xx:3306. Skipping.
[...]
Info: Using database Streptococcus_uberis at @xx:3306
[@xx:3306 Streptococcus_uberis.contig_data]: 0 0 contig_001
Info: Using database Streptomyces_coelicolor_A3_2 at @xx:3306
[@xx:3306 Streptomyces_coelicolor_A3_2.contig_data]: 0 0 NC_003888
Info: Using database Sulfolobus_solfataricus_P2 at @xx:3306
[@xx:3306 Sulfolobus_solfataricus_P2.contig_data]: 0 0 AE006641
Info: Using database Sulfolobus_tokodaii at @xx:3306
[@xx:3306 Sulfolobus_tokodaii.contig_data]: 0 0 Sulfolobus_tokodaii
Info: Using database Synechococcus_sp at @xx:3306
[@xx:3306 Synechococcus_sp.contig_data]: 0 0 Scaffold_1
Info: Using database Synechocystis_PCC6803 at @xx:3306
[@xx:3306 Synechocystis_PCC6803.contig_data]: 0 0 Synechocystis_PCC6803
Info: Using database TEACHING_TEST at @xx:3306
Info: Using database Tacidophilum at @xx:3306
[@xx:3306 Tacidophilum.contig_data]: 0 0 Tacidophilum
Info: Using database Tfusca at @xx:3306
Info: Using database Thermoanaerobacter_tengcongensis_MB4T at @xx:3306
[@xx:3306 Thermoanaerobacter_tengcongensis_MB4T.contig_data]: 0 0 NC_003869
Info: Using database Thermoplasma_volcanium_GSS1 at @xx:3306
[@xx:3306 Thermoplasma_volcanium_GSS1.contig_data]: 0 0 NC_002689
Info: Using database Thermosynechococcus_elongatus_BP1 at @xx:3306
[@xx:3306 Thermosynechococcus_elongatus_BP1.contig_data]: 0 0 NC_004113
Info: Using database Thermotoga_maritima_MSB8 at @xx:3306
[@xx:3306 Thermotoga_maritima_MSB8.contig_data]: 0 0 AE000512
Info: Using database Treponema_denticola_ATCC35405 at @xx:3306
Error: [@xx:3306 Treponema_denticola_ATCC35405.contig_data]: (execute failed): Got error 127 from table handler
Info: Using database Treponema_pallidum_Nichols at @xx:3306
[@xx:3306 Treponema_pallidum_Nichols.contig_data]: 0 0 Treponema_pallidum_Nichols
Info: Using database Trichodesmium_erythraeum_IMS101 at @xx:3306
[@xx:3306 Trichodesmium_erythraeum_IMS101.contig_data]: 0 0 scaffold_1
Info: Using database Tropheryma_whippelii at @xx:3306
[@xx:3306 Tropheryma_whippelii.contig_data]: 0 0 whip086a06_p1k
The stack I've posted here recently:
http://lists.mysql.com/cgi-ez/ezmlm-cgi?9:mss:13530:200301:l lpikeeodfbcnpcllnnd
> On Wednesday 29 January 2003 21:03, Martin MOKREJÅ wrote:
> > On Tue, 28 Jan 2003, Martin MOKREJ wrote:
> >
> > It happened today about 7 times already. How can I start
> > mysqld so that it doesn't fork? I want only one thread!
>
> If it is increased frequently this may mean something is going
> bad with the data.
$ vmstat 1
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
0 0 0 10308 82980 22300 774708 7 4 13 14 17 6 0 2 5
0 0 0 10308 82660 22300 774912 0 0 204 0 147 72 0 1 99
1 0 1 10308 81036 22316 774912 0 0 0 177 154 67 6 0 94
1 0 0 10308 68928 22316 775040 0 0 128 0 127 51 46 5 49
1 0 0 10308 65124 22316 775312 0 0 272 0 140 958 44 3 52
0 0 0 10308 78680 22316 775312 0 0 0 0 142 257 12 0 88
0 0 0 10308 78692 22316 775312 0 0 0 0 109 10 0 0 100
[...]
A these moments I've crashed mysqld several times by intention.
I'm doing primitive selct on some rather small tables.
>
> Did you check the tables with extended option as I adviced ?
>
> Also why do you need single thread mode (I never had need to use
> it) if you would like to spot the error compile with debugging
> is usually better way.
>
> One thread mode will not allow more than one client to connect so
> you will not able to debug it anywaya
So I've set thread concurrency to 1. Is that the right place?
Another demonstration:
# strace -v -v -v -f -p 3625 > /data/strace.$$.log 2>&1
Number of processes running now: 2
mysqld process hanging, pid 3949 - killed
mysqld process hanging, pid 3625 - killed
030129 20:12:37 mysqld restarted
030129 20:12:37 mysqld ended
just select on 2 columns in one table. 2 such table are marked as crashed.
One is in Caenorhabditis_elegans_WS75, second is in Drosophila_melanogaster.
[...]
Info: Using database Clostridium_difficile_630 at @xx:3306
[@xx:3306 Clostridium_difficile_630.contig_data]: 0 0 contig710.0.0
Info: Using database Clostridium_perfringens_13 at @xx:3306
[@xx:3306 Clostridium_perfringens_13.contig_data]: 0 0 NC_003042
Info: Using database Clostridium_thermocellum_ATCC27405 at @xx:3306
Error: [@xx:3306 Clostridium_thermocellum_ATCC27405.contig_data]: (execute failed): Got error 127 from table handler
Info: Using database Corynebacterium_diphteriae_NCTC_13129 at @xx:3306
[@xx:3306 Corynebacterium_diphteriae_NCTC_13129.contig_data]: 0 0 CDIP
Info: Using database Corynebacterium_efficiens_YS314T at @xx:3306
[@xx:3306 Corynebacterium_efficiens_YS314T.contig_data]: 0 0 NC_004369
Info: Using database Corynebacterium_glutamicum at @xx:3306
[@xx:3306 Corynebacterium_glutamicum.contig_data]: 0 0 NC_003450
Info: Using database CpneumoniaeAR39 at @xx:3306
[@xx:3306 CpneumoniaeAR39.contig_data]: 0 0 CpneumoniaeAR39
Info: Using database Cpneumoniae_CWL029 at @xx:3306
[@xx:3306 Cpneumoniae_CWL029.contig_data]: 0 0 Cpneumoniae_CWL029
Info: Using database Ctrachomatis at @xx:3306
[@xx:3306 Ctrachomatis.contig_data]: 0 0 Ctrachomatis
Info: Using database Cyanidium_caldarium_chloroplast at @xx:3306
[@xx:3306 Cyanidium_caldarium_chloroplast.contig_data]: 0 0 NC_001840
Info: Using database Debaryomyces_hansenii_CBS_767 at @xx:3306
Info: Using database Deinococcus_radiodurans_R1 at @xx:3306
[@xx:3306 Deinococcus_radiodurans_R1.contig_data]: 0 0 NC_000958
Info: Using database Desulfitobacterium_hafniense_DCB2 at @xx:3306
[@xx:3306 Desulfitobacterium_hafniense_DCB2.contig_data]: 0 0 2351519_fasta_screen_Contig1000
Info: Using database Drosophila_melanogaster at @xx:3306
Error: [@xx:3306 Drosophila_melanogaster.contig_data]: (execute failed): Can't open file: 'contig_data.MYD'. (errno: 145)
Info: Using database Efaecalis at @xx:3306
Warning: Efaecalis.contig_data does not exist, skipping command execution
Info: Using database Encephalitozoon_cuniculi at @xx:3306
After I've cancelled my strace process, I got back on terminal where the program ran:
Error: [@xx:3306 Encephalitozoon_cuniculi.contig_data]: (execute failed): Lost connection to MySQL server during query
Error: [@xx:3306 Erwinia_carotovora_atroseptica]: Can't connect to MySQL server on 'xx' (111)
Error: Cannot use database Erwinia_carotovora_atroseptica on xx:3306. Skipping.
Error: [@xx:3306 Escherichia_coli_CFT073]: Can't connect to MySQL server on 'xx' (111)
Error: Cannot use database Escherichia_coli_CFT073 on xx:3306. Skipping.
Error: [@xx:3306 Escherichia_coli_K12]: Can't connect to MySQL server on 'xx' (111)
Error: Cannot use database Escherichia_coli_K12 on xx:3306. Skipping.
[...]
I'd like to you to point you to lines 6180-6251 in the strace file,
(http://pedant.gsf.de/strace.12202.log)
6238 [pid 3949] getcwd("/data/mysql", 4095) = 12
6239 [pid 3949] lstat64("/data/mysql/Caenorhabditis_elegans_WS75", {st_dev=makedev(58, 0), st_ino=7208961, st_mode=S_IFDIR|0700, st_nlink=2, st_uid=1005, st_gid=101, st_blksize=4096, st_blocks=8, st_size=4096, st_atime=2003/01/29-20:12:36, st_mtime=2003/01/27-18:32:19, st_ctime=2003/01/27-18:32:19}) = 0
6240 [pid 3949] lstat64("/data/mysql/Caenorhabditis_elegans_WS75/contig_data .MYI", {st_dev=makedev(58, 0), st_ino=7208990, st_mode=S_IFREG|0660, st_nlink=1, st_uid=1005, st_gid=101, st_blksize=4096, st_blocks=8, st_size=1024, st_atime=2003/01/29-20:10:14, st_mtime=2003/01/29-19:25:36, st_ctime=2003/01/29-19:25:36}) = 0
6241 [pid 3949] open("/data/mysql/Caenorhabditis_elegans_WS75/contig_data.MY I", O_RDWR|O_LARGEFILE) = 84
6242 [pid 3949] read(84, "\376\376\7\1\0\7\2.\0\260\0d\0\374\0\5\0\0\5\0\10\2\0\0"... , 24) = 24
6243 [pid 3949] readlink("./Caenorhabditis_elegans_WS75/contig_data.MYI", 0xbff5e7e4, 511) = -1 EINVAL (Invalid argument)
6244 [pid 3949] readlink("./Caenorhabditis_elegans_WS75/contig_data.MYD", 0xbff5e5e4, 511) = -1 EINVAL (Invalid argument)
6245 [pid 3949] _llseek(84, 0, [0], SEEK_SET) = 0
6246 [pid 3949] read(84, "\376\376\7\1\0\7\2.\0\260\0d\0\374\0\5\0\0\5\0\10\2\0\0"... , 558) = 558
6247 [pid 3949] close(84) = 0
6248 [pid 3949] write(7, "3\0\0\1\377\370\3Can\'t open file: \'contig_"..., 55) = 55
6249 [pid 3949] sched_setscheduler(0xf6d, 0, 0xbff5f8c0) = -1 EINVAL (Invalid argument)
6250 [pid 3949] time([1043867556]) = 1043867556
6251 [pid 3949] read(7, "$\0\0\0", 4) = 4
then lines 8694-8778 regarding Drosophila_melanogaster.
The crash is here:
8882 [pid 3949] getcwd("/data/mysql", 4095) = 12
8883 [pid 3949] lstat64("/data/mysql/Encephalitozoon_cuniculi", {st_dev=makedev(58, 0), st_ino=12107777, st_mode=S_IFDIR|0700, st_nlink=2, st_uid=1005, st_gid=101, st_blksize=4096, st_blocks=8, st_size=4096, st_atime=2003/01/29-20:12:37, st_mtime=2003/01/28-05:49:35, st_ctime=2003/01/28-05:49:35}) = 0
8884 [pid 3949] lstat64("/data/mysql/Encephalitozoon_cuniculi/contig_data.MY I", {st_dev=makedev(58, 0), st_ino=12107810, st_mode=S_IFREG|0660, st_nlink=1, st_uid=1005, st_gid=101, st_blksize=4096, st_blocks=16, st_size=7168, st_atime=2003/01/29-20:10:15, st_mtime=2003/01/28-05:46:35, st_ctime=2003/01/28-05:46:35}) = 0
8885 [pid 3949] open("/data/mysql/Encephalitozoon_cuniculi/contig_data.MYI", O_RDWR|O_LARGEFILE) = 138
8886 [pid 3949] read(138, "\376\376\7\1\0\7\2.\0\260\0d\0\374\0\5\0\0\5\0\10\2\0\0"... , 24) = 24
8887 [pid 3949] readlink("./Encephalitozoon_cuniculi/contig_data.MYI", 0xbff5e7e4, 511) = -1 EINVAL (Invalid argument)
8888 [pid 3949] readlink("./Encephalitozoon_cuniculi/contig_data.MYD", 0xbff5e5e4, 511) = -1 EINVAL (Invalid argument)
8889 [pid 3949] _llseek(138, 0, [0], SEEK_SET) = 0
8890 [pid 3949] read(138, "\376\376\7\1\0\7\2.\0\260\0d\0\374\0\5\0\0\5\0\10\2\0\0"... , 558) = 558
8891 [pid 3949] open("./Encephalitozoon_cuniculi/contig_data.MYD", O_RDWR|O_LARGEFILE) = 139
8892 [pid 3949] getpid() = 3949
8893 [pid 3949] read(139, "\376\376\10\1\226\0\0\0\26\324\0\0Q%\1\0005\0\0\0\0\0\0"... , 32) = 32
8894 [pid 3949] old_mmap(0x594fa000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x594fa000
8895 [pid 3949] read(139, "\0\0\0A\200 \301\0\340\200p@@\200N\20\16\0\f\20X\275\213"..., 118) = 118
8896 [pid 3949] old_mmap(0x594fb000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x594fb000
8897 [pid 3949] old_mmap(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x55354000
8898 [pid 3949] munmap(0x55354000, 704512) = 0
8899 [pid 3949] munmap(0x55500000, 344064) = 0
8900 [pid 3949] old_mmap(0x55400000, 77824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x55400000
8901 [pid 3949] time([1043867557]) = 1043867557
8902 [pid 3949] pread(138, "\0Z\0\0\0\0\0\0\0\226\0\0\0\1\0\0\347w\0\0\0\2\0\1\276"..., 1024, 1024) = 1024
8903 [pid 3949] _llseek(139, 150, [150], SEEK_SET) = 0
8904 [pid 3949] read(139, "\376\332\346\377>4\3O", 8) = 8
8905 [pid 3949] old_mmap(NULL, 270336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x55354000
8906 [pid 3949] munmap(0x55400000, 1048576) = 0
8907 [pid 3949] --- SIGSEGV (Segmentation fault) ---
8908 <... poll resumed> [{fd=5, events=POLLIN, revents=POLLIN}], 1, 2000) = 1
8909 getppid() = 3623
8910 read(5, "\0\374\365\277\2\0\0\0\1\0\0\0\200\313<\10\1\0\0\0X\352"..., 148) = 148
8911 kill(3626, SIGRT_1) = 0
8912 --- SIGRT_1 (Real-time signal 1) ---
8913 sigreturn() = ? (mask now ~[TRAP KILL STOP])
8914 kill(3623, SIGRT_1) = 0
8915 wait4(3626,
As the file number was increasing, I guess the tables have been in the tablecache.
Any suggestions what to put into my.cnf regarding debugging?:
Which one?
##default is d:i:t:o,/tmp/mysqld.trace
##debug = d:i:t:o,/tmp/mysqld.trace
##debug = d,info,query,general:o,/tmp/mysqld.trace
#debug = d,info,general,query
--
Martin Mokrejs ,
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13630@lists.mysql.com
To unsubscribe, e-mail
Re: crash with 4.0.9 on linux
am 29.01.2003 20:41:02 von mmokrejs
On Wed, 29 Jan 2003, Peter Zaitsev wrote:
Hi,
I've managed to reproduce this once. I've a script doing slect on every
database on same table. Two such tables are broken (I've no clue if this
is really needed).
How-To-Repeat:
Info: Using database Clostridium_acetobutylicum_ATCC824 at @xx:3306
[@xx:3306 Clostridium_acetobutylicum_ATCC824.contig_data]: 0 0 Clostridium_acetobutylicum_ATCC824
Info: Using database Clostridium_botulinum_A at @xx:3306
[@xx:3306 Clostridium_botulinum_A.contig_data]: 0 0 contig1
Info: Using database Clostridium_difficile_630 at @xx:3306
[@xx:3306 Clostridium_difficile_630.contig_data]: 0 0 contig710.0.0
Info: Using database Clostridium_perfringens_13 at @xx:3306
[@xx:3306 Clostridium_perfringens_13.contig_data]: 0 0 NC_003042
Info: Using database Clostridium_thermocellum_ATCC27405 at @xx:3306
Error: [@xx:3306 Clostridium_thermocellum_ATCC27405.contig_data]: (execute failed): Lost connection to MySQL server during query
Error: [@xx:3306 Corynebacterium_diphteriae_NCTC_13129]: Can't connect to MySQL server on 'xx' (111)
Error: Cannot use database Corynebacterium_diphteriae_NCTC_13129 on xx:3306. Skipping.
Error: [@xx:3306 Corynebacterium_efficiens_YS314T]: Can't connect to MySQL server on 'xx' (111)
Error: Cannot use database Corynebacterium_efficiens_YS314T on xx:3306. Skipping.
[...]
Info: Using database Streptococcus_uberis at @xx:3306
[@xx:3306 Streptococcus_uberis.contig_data]: 0 0 contig_001
Info: Using database Streptomyces_coelicolor_A3_2 at @xx:3306
[@xx:3306 Streptomyces_coelicolor_A3_2.contig_data]: 0 0 NC_003888
Info: Using database Sulfolobus_solfataricus_P2 at @xx:3306
[@xx:3306 Sulfolobus_solfataricus_P2.contig_data]: 0 0 AE006641
Info: Using database Sulfolobus_tokodaii at @xx:3306
[@xx:3306 Sulfolobus_tokodaii.contig_data]: 0 0 Sulfolobus_tokodaii
Info: Using database Synechococcus_sp at @xx:3306
[@xx:3306 Synechococcus_sp.contig_data]: 0 0 Scaffold_1
Info: Using database Synechocystis_PCC6803 at @xx:3306
[@xx:3306 Synechocystis_PCC6803.contig_data]: 0 0 Synechocystis_PCC6803
Info: Using database TEACHING_TEST at @xx:3306
Info: Using database Tacidophilum at @xx:3306
[@xx:3306 Tacidophilum.contig_data]: 0 0 Tacidophilum
Info: Using database Tfusca at @xx:3306
Info: Using database Thermoanaerobacter_tengcongensis_MB4T at @xx:3306
[@xx:3306 Thermoanaerobacter_tengcongensis_MB4T.contig_data]: 0 0 NC_003869
Info: Using database Thermoplasma_volcanium_GSS1 at @xx:3306
[@xx:3306 Thermoplasma_volcanium_GSS1.contig_data]: 0 0 NC_002689
Info: Using database Thermosynechococcus_elongatus_BP1 at @xx:3306
[@xx:3306 Thermosynechococcus_elongatus_BP1.contig_data]: 0 0 NC_004113
Info: Using database Thermotoga_maritima_MSB8 at @xx:3306
[@xx:3306 Thermotoga_maritima_MSB8.contig_data]: 0 0 AE000512
Info: Using database Treponema_denticola_ATCC35405 at @xx:3306
Error: [@xx:3306 Treponema_denticola_ATCC35405.contig_data]: (execute failed): Got error 127 from table handler
Info: Using database Treponema_pallidum_Nichols at @xx:3306
[@xx:3306 Treponema_pallidum_Nichols.contig_data]: 0 0 Treponema_pallidum_Nichols
Info: Using database Trichodesmium_erythraeum_IMS101 at @xx:3306
[@xx:3306 Trichodesmium_erythraeum_IMS101.contig_data]: 0 0 scaffold_1
Info: Using database Tropheryma_whippelii at @xx:3306
[@xx:3306 Tropheryma_whippelii.contig_data]: 0 0 whip086a06_p1k
The stack I've posted here recently:
http://lists.mysql.com/cgi-ez/ezmlm-cgi?9:mss:13530:200301:l lpikeeodfbcnpcllnnd
> On Wednesday 29 January 2003 21:03, Martin MOKREJÅ wrote:
> > On Tue, 28 Jan 2003, Martin MOKREJ wrote:
> >
> > It happened today about 7 times already. How can I start
> > mysqld so that it doesn't fork? I want only one thread!
>
> If it is increased frequently this may mean something is going
> bad with the data.
$ vmstat 1
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
0 0 0 10308 82980 22300 774708 7 4 13 14 17 6 0 2 5
0 0 0 10308 82660 22300 774912 0 0 204 0 147 72 0 1 99
1 0 1 10308 81036 22316 774912 0 0 0 177 154 67 6 0 94
1 0 0 10308 68928 22316 775040 0 0 128 0 127 51 46 5 49
1 0 0 10308 65124 22316 775312 0 0 272 0 140 958 44 3 52
0 0 0 10308 78680 22316 775312 0 0 0 0 142 257 12 0 88
0 0 0 10308 78692 22316 775312 0 0 0 0 109 10 0 0 100
[...]
A these moments I've crashed mysqld several times by intention.
I'm doing primitive selct on some rather small tables.
>
> Did you check the tables with extended option as I adviced ?
>
> Also why do you need single thread mode (I never had need to use
> it) if you would like to spot the error compile with debugging
> is usually better way.
>
> One thread mode will not allow more than one client to connect so
> you will not able to debug it anywaya
So I've set thread concurrency to 1. Is that the right place?
Another demonstration:
# strace -v -v -v -f -p 3625 > /data/strace.$$.log 2>&1
Number of processes running now: 2
mysqld process hanging, pid 3949 - killed
mysqld process hanging, pid 3625 - killed
030129 20:12:37 mysqld restarted
030129 20:12:37 mysqld ended
just select on 2 columns in one table. 2 such table are marked as crashed.
One is in Caenorhabditis_elegans_WS75, second is in Drosophila_melanogaster.
[...]
Info: Using database Clostridium_difficile_630 at @xx:3306
[@xx:3306 Clostridium_difficile_630.contig_data]: 0 0 contig710.0.0
Info: Using database Clostridium_perfringens_13 at @xx:3306
[@xx:3306 Clostridium_perfringens_13.contig_data]: 0 0 NC_003042
Info: Using database Clostridium_thermocellum_ATCC27405 at @xx:3306
Error: [@xx:3306 Clostridium_thermocellum_ATCC27405.contig_data]: (execute failed): Got error 127 from table handler
Info: Using database Corynebacterium_diphteriae_NCTC_13129 at @xx:3306
[@xx:3306 Corynebacterium_diphteriae_NCTC_13129.contig_data]: 0 0 CDIP
Info: Using database Corynebacterium_efficiens_YS314T at @xx:3306
[@xx:3306 Corynebacterium_efficiens_YS314T.contig_data]: 0 0 NC_004369
Info: Using database Corynebacterium_glutamicum at @xx:3306
[@xx:3306 Corynebacterium_glutamicum.contig_data]: 0 0 NC_003450
Info: Using database CpneumoniaeAR39 at @xx:3306
[@xx:3306 CpneumoniaeAR39.contig_data]: 0 0 CpneumoniaeAR39
Info: Using database Cpneumoniae_CWL029 at @xx:3306
[@xx:3306 Cpneumoniae_CWL029.contig_data]: 0 0 Cpneumoniae_CWL029
Info: Using database Ctrachomatis at @xx:3306
[@xx:3306 Ctrachomatis.contig_data]: 0 0 Ctrachomatis
Info: Using database Cyanidium_caldarium_chloroplast at @xx:3306
[@xx:3306 Cyanidium_caldarium_chloroplast.contig_data]: 0 0 NC_001840
Info: Using database Debaryomyces_hansenii_CBS_767 at @xx:3306
Info: Using database Deinococcus_radiodurans_R1 at @xx:3306
[@xx:3306 Deinococcus_radiodurans_R1.contig_data]: 0 0 NC_000958
Info: Using database Desulfitobacterium_hafniense_DCB2 at @xx:3306
[@xx:3306 Desulfitobacterium_hafniense_DCB2.contig_data]: 0 0 2351519_fasta_screen_Contig1000
Info: Using database Drosophila_melanogaster at @xx:3306
Error: [@xx:3306 Drosophila_melanogaster.contig_data]: (execute failed): Can't open file: 'contig_data.MYD'. (errno: 145)
Info: Using database Efaecalis at @xx:3306
Warning: Efaecalis.contig_data does not exist, skipping command execution
Info: Using database Encephalitozoon_cuniculi at @xx:3306
After I've cancelled my strace process, I got back on terminal where the program ran:
Error: [@xx:3306 Encephalitozoon_cuniculi.contig_data]: (execute failed): Lost connection to MySQL server during query
Error: [@xx:3306 Erwinia_carotovora_atroseptica]: Can't connect to MySQL server on 'xx' (111)
Error: Cannot use database Erwinia_carotovora_atroseptica on xx:3306. Skipping.
Error: [@xx:3306 Escherichia_coli_CFT073]: Can't connect to MySQL server on 'xx' (111)
Error: Cannot use database Escherichia_coli_CFT073 on xx:3306. Skipping.
Error: [@xx:3306 Escherichia_coli_K12]: Can't connect to MySQL server on 'xx' (111)
Error: Cannot use database Escherichia_coli_K12 on xx:3306. Skipping.
[...]
I'd like to you to point you to lines 6180-6251 in the strace file,
(http://pedant.gsf.de/strace.12202.log)
6238 [pid 3949] getcwd("/data/mysql", 4095) = 12
6239 [pid 3949] lstat64("/data/mysql/Caenorhabditis_elegans_WS75", {st_dev=makedev(58, 0), st_ino=7208961, st_mode=S_IFDIR|0700, st_nlink=2, st_uid=1005, st_gid=101, st_blksize=4096, st_blocks=8, st_size=4096, st_atime=2003/01/29-20:12:36, st_mtime=2003/01/27-18:32:19, st_ctime=2003/01/27-18:32:19}) = 0
6240 [pid 3949] lstat64("/data/mysql/Caenorhabditis_elegans_WS75/contig_data .MYI", {st_dev=makedev(58, 0), st_ino=7208990, st_mode=S_IFREG|0660, st_nlink=1, st_uid=1005, st_gid=101, st_blksize=4096, st_blocks=8, st_size=1024, st_atime=2003/01/29-20:10:14, st_mtime=2003/01/29-19:25:36, st_ctime=2003/01/29-19:25:36}) = 0
6241 [pid 3949] open("/data/mysql/Caenorhabditis_elegans_WS75/contig_data.MY I", O_RDWR|O_LARGEFILE) = 84
6242 [pid 3949] read(84, "\376\376\7\1\0\7\2.\0\260\0d\0\374\0\5\0\0\5\0\10\2\0\0"... , 24) = 24
6243 [pid 3949] readlink("./Caenorhabditis_elegans_WS75/contig_data.MYI", 0xbff5e7e4, 511) = -1 EINVAL (Invalid argument)
6244 [pid 3949] readlink("./Caenorhabditis_elegans_WS75/contig_data.MYD", 0xbff5e5e4, 511) = -1 EINVAL (Invalid argument)
6245 [pid 3949] _llseek(84, 0, [0], SEEK_SET) = 0
6246 [pid 3949] read(84, "\376\376\7\1\0\7\2.\0\260\0d\0\374\0\5\0\0\5\0\10\2\0\0"... , 558) = 558
6247 [pid 3949] close(84) = 0
6248 [pid 3949] write(7, "3\0\0\1\377\370\3Can\'t open file: \'contig_"..., 55) = 55
6249 [pid 3949] sched_setscheduler(0xf6d, 0, 0xbff5f8c0) = -1 EINVAL (Invalid argument)
6250 [pid 3949] time([1043867556]) = 1043867556
6251 [pid 3949] read(7, "$\0\0\0", 4) = 4
then lines 8694-8778 regarding Drosophila_melanogaster.
The crash is here:
8882 [pid 3949] getcwd("/data/mysql", 4095) = 12
8883 [pid 3949] lstat64("/data/mysql/Encephalitozoon_cuniculi", {st_dev=makedev(58, 0), st_ino=12107777, st_mode=S_IFDIR|0700, st_nlink=2, st_uid=1005, st_gid=101, st_blksize=4096, st_blocks=8, st_size=4096, st_atime=2003/01/29-20:12:37, st_mtime=2003/01/28-05:49:35, st_ctime=2003/01/28-05:49:35}) = 0
8884 [pid 3949] lstat64("/data/mysql/Encephalitozoon_cuniculi/contig_data.MY I", {st_dev=makedev(58, 0), st_ino=12107810, st_mode=S_IFREG|0660, st_nlink=1, st_uid=1005, st_gid=101, st_blksize=4096, st_blocks=16, st_size=7168, st_atime=2003/01/29-20:10:15, st_mtime=2003/01/28-05:46:35, st_ctime=2003/01/28-05:46:35}) = 0
8885 [pid 3949] open("/data/mysql/Encephalitozoon_cuniculi/contig_data.MYI", O_RDWR|O_LARGEFILE) = 138
8886 [pid 3949] read(138, "\376\376\7\1\0\7\2.\0\260\0d\0\374\0\5\0\0\5\0\10\2\0\0"... , 24) = 24
8887 [pid 3949] readlink("./Encephalitozoon_cuniculi/contig_data.MYI", 0xbff5e7e4, 511) = -1 EINVAL (Invalid argument)
8888 [pid 3949] readlink("./Encephalitozoon_cuniculi/contig_data.MYD", 0xbff5e5e4, 511) = -1 EINVAL (Invalid argument)
8889 [pid 3949] _llseek(138, 0, [0], SEEK_SET) = 0
8890 [pid 3949] read(138, "\376\376\7\1\0\7\2.\0\260\0d\0\374\0\5\0\0\5\0\10\2\0\0"... , 558) = 558
8891 [pid 3949] open("./Encephalitozoon_cuniculi/contig_data.MYD", O_RDWR|O_LARGEFILE) = 139
8892 [pid 3949] getpid() = 3949
8893 [pid 3949] read(139, "\376\376\10\1\226\0\0\0\26\324\0\0Q%\1\0005\0\0\0\0\0\0"... , 32) = 32
8894 [pid 3949] old_mmap(0x594fa000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x594fa000
8895 [pid 3949] read(139, "\0\0\0A\200 \301\0\340\200p@@\200N\20\16\0\f\20X\275\213"..., 118) = 118
8896 [pid 3949] old_mmap(0x594fb000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x594fb000
8897 [pid 3949] old_mmap(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x55354000
8898 [pid 3949] munmap(0x55354000, 704512) = 0
8899 [pid 3949] munmap(0x55500000, 344064) = 0
8900 [pid 3949] old_mmap(0x55400000, 77824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x55400000
8901 [pid 3949] time([1043867557]) = 1043867557
8902 [pid 3949] pread(138, "\0Z\0\0\0\0\0\0\0\226\0\0\0\1\0\0\347w\0\0\0\2\0\1\276"..., 1024, 1024) = 1024
8903 [pid 3949] _llseek(139, 150, [150], SEEK_SET) = 0
8904 [pid 3949] read(139, "\376\332\346\377>4\3O", 8) = 8
8905 [pid 3949] old_mmap(NULL, 270336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x55354000
8906 [pid 3949] munmap(0x55400000, 1048576) = 0
8907 [pid 3949] --- SIGSEGV (Segmentation fault) ---
8908 <... poll resumed> [{fd=5, events=POLLIN, revents=POLLIN}], 1, 2000) = 1
8909 getppid() = 3623
8910 read(5, "\0\374\365\277\2\0\0\0\1\0\0\0\200\313<\10\1\0\0\0X\352"..., 148) = 148
8911 kill(3626, SIGRT_1) = 0
8912 --- SIGRT_1 (Real-time signal 1) ---
8913 sigreturn() = ? (mask now ~[TRAP KILL STOP])
8914 kill(3623, SIGRT_1) = 0
8915 wait4(3626,
As the file number was increasing, I guess the tables have been in the tablecache.
Any suggestions what to put into my.cnf regarding debugging?:
Which one?
##default is d:i:t:o,/tmp/mysqld.trace
##debug = d:i:t:o,/tmp/mysqld.trace
##debug = d,info,query,general:o,/tmp/mysqld.trace
#debug = d,info,general,query
--
Martin Mokrejs ,
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13631@lists.mysql.com
To unsubscribe, e-mail
Re: crash with 4.0.9 on linux
am 29.01.2003 21:10:37 von mmokrejs
Hi,
another attempt with older mysql version from bitkeeper with debug
enabled:
http://pedant.gsf.de/mysqld.trace-crash.out - output of my script
http://pedant.gsf.de/mysqld.trace-crash - trace file, unfortunately
it does not list the database names, so
I'm not sure how can you find the relevant rows.
http://pedant.gsf.de/Erwinia_carotovora_atroseptica.tgz
- the table causing crashes
--
Martin Mokrejs ,
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13632@lists.mysql.com
To unsubscribe, e-mail
Re: crash with 4.0.9 on linux
am 29.01.2003 21:19:51 von Peter Zaitsev
On Wednesday 29 January 2003 22:35, Martin MOKREJÅ wrote:
> On Wed, 29 Jan 2003, Peter Zaitsev wrote:
Marten,
Let us start over.
Did you mannage to
-check and repair all the tables
- start MySQL ensuring noone can possibly touch the same files
- run your script
and so run into table corruption ?
If this is the case I would ask you to try to provide minimum
test case (one table + small script would be the best)
and upload it.
This would help us to fix the bug.
I'm not MyISAM low level specialist also it is really hard to
work only with strace data.
>
> Hi,
> I've managed to reproduce this once. I've a script doing
> slect on every database on same table. Two such tables are
> broken (I've no clue if this is really needed).
>
> Info: Using database Clostridium_acetobutylicum_ATCC824 at
> @xx:3306 [@xx:3306
> Clostridium_acetobutylicum_ATCC824.contig_data]: 0 0
> Clostridium_acetobutylicum_ATCC824 Info: Using database
> Clostridium_botulinum_A at @xx:3306 [@xx:3306
> Clostridium_botulinum_A.contig_data]: 0 0 contig1 Info: Using
> database Clostridium_difficile_630 at @xx:3306 [@xx:3306
> Clostridium_difficile_630.contig_data]: 0 0 contig710.0.0
> Info: Using database Clostridium_perfringens_13 at @xx:3306
> [@xx:3306 Clostridium_perfringens_13.contig_data]: 0 0
> NC_003042 Info: Using database
> Clostridium_thermocellum_ATCC27405 at @xx:3306 Error:
> [@xx:3306 Clostridium_thermocellum_ATCC27405.contig_data]:
> (execute failed): Lost connection to MySQL server during query
> Error: [@xx:3306 Corynebacterium_diphteriae_NCTC_13129]: Can't
> connect to MySQL server on 'xx' (111) Error: Cannot use
> database Corynebacterium_diphteriae_NCTC_13129 on xx:3306.
> Skipping. Error: [@xx:3306 Corynebacterium_efficiens_YS314T]:
> Can't connect to MySQL server on 'xx' (111) Error: Cannot use
> database Corynebacterium_efficiens_YS314T on xx:3306.
> Skipping. [...]
> Info: Using database Streptococcus_uberis at @xx:3306
> [@xx:3306 Streptococcus_uberis.contig_data]: 0 0 contig_001
> Info: Using database Streptomyces_coelicolor_A3_2 at @xx:3306
> [@xx:3306 Streptomyces_coelicolor_A3_2.contig_data]: 0 0
> NC_003888 Info: Using database Sulfolobus_solfataricus_P2 at
> @xx:3306 [@xx:3306 Sulfolobus_solfataricus_P2.contig_data]: 0
> 0 AE006641 Info: Using database Sulfolobus_tokodaii at
> @xx:3306
> [@xx:3306 Sulfolobus_tokodaii.contig_data]: 0 0
> Sulfolobus_tokodaii Info: Using database Synechococcus_sp at
> @xx:3306
> [@xx:3306 Synechococcus_sp.contig_data]: 0 0 Scaffold_1
> Info: Using database Synechocystis_PCC6803 at @xx:3306
> [@xx:3306 Synechocystis_PCC6803.contig_data]: 0 0
> Synechocystis_PCC6803 Info: Using database TEACHING_TEST at
> @xx:3306
> Info: Using database Tacidophilum at @xx:3306
> [@xx:3306 Tacidophilum.contig_data]: 0 0 Tacidophilum
> Info: Using database Tfusca at @xx:3306
> Info: Using database Thermoanaerobacter_tengcongensis_MB4T at
> @xx:3306 [@xx:3306
> Thermoanaerobacter_tengcongensis_MB4T.contig_data]: 0 0
> NC_003869 Info: Using database Thermoplasma_volcanium_GSS1 at
> @xx:3306 [@xx:3306 Thermoplasma_volcanium_GSS1.contig_data]: 0
> 0 NC_002689 Info: Using database
> Thermosynechococcus_elongatus_BP1 at @xx:3306 [@xx:3306
> Thermosynechococcus_elongatus_BP1.contig_data]: 0 0 NC_004113
> Info: Using database Thermotoga_maritima_MSB8 at @xx:3306
> [@xx:3306 Thermotoga_maritima_MSB8.contig_data]: 0 0 AE000512
> Info: Using database Treponema_denticola_ATCC35405 at @xx:3306
> Error: [@xx:3306 Treponema_denticola_ATCC35405.contig_data]:
> (execute failed): Got error 127 from table handler Info: Using
> database Treponema_pallidum_Nichols at @xx:3306 [@xx:3306
> Treponema_pallidum_Nichols.contig_data]: 0 0
> Treponema_pallidum_Nichols Info: Using database
> Trichodesmium_erythraeum_IMS101 at @xx:3306 [@xx:3306
> Trichodesmium_erythraeum_IMS101.contig_data]: 0 0 scaffold_1
> Info: Using database Tropheryma_whippelii at @xx:3306
> [@xx:3306 Tropheryma_whippelii.contig_data]: 0 0
> whip086a06_p1k
>
>
> The stack I've posted here recently:
>
> http://lists.mysql.com/cgi-ez/ezmlm-cgi?9:mss:13530:200301:l lp
>ikeeodfbcnpcllnnd
>
> > On Wednesday 29 January 2003 21:03, Martin MOKREJÅ wrote:
> > > On Tue, 28 Jan 2003, Martin MOKREJ wrote:
> > >
> > > It happened today about 7 times already. How can I start
> > > mysqld so that it doesn't fork? I want only one thread!
> >
> > If it is increased frequently this may mean something is
> > going bad with the data.
>
> $ vmstat 1
> procs memory swap io
> system cpu r b w swpd free buff cache si so
> bi bo in cs us sy id 0 0 0 10308 82980
> 22300 774708 7 4 13 14 17 6 0 2 5 0 0
> 0 10308 82660 22300 774912 0 0 204 0 147 72
> 0 1 99 1 0 1 10308 81036 22316 774912 0 0 0
> 177 154 67 6 0 94 1 0 0 10308 68928 22316 775040
> 0 0 128 0 127 51 46 5 49 1 0 0 10308
> 65124 22316 775312 0 0 272 0 140 958 44 3 52
> 0 0 0 10308 78680 22316 775312 0 0 0 0 142
> 257 12 0 88 0 0 0 10308 78692 22316 775312 0 0
> 0 0 109 10 0 0 100 [...]
>
> A these moments I've crashed mysqld several times by
> intention. I'm doing primitive selct on some rather small
> tables.
>
> > Did you check the tables with extended option as I adviced ?
> >
> > Also why do you need single thread mode (I never had need to
> > use it) if you would like to spot the error compile with
> > debugging is usually better way.
> >
> > One thread mode will not allow more than one client to
> > connect so you will not able to debug it anywaya
>
> So I've set thread concurrency to 1. Is that the right place?
>
>
> Another demonstration:
>
> # strace -v -v -v -f -p 3625 > /data/strace.$$.log 2>&1
>
> Number of processes running now: 2
> mysqld process hanging, pid 3949 - killed
> mysqld process hanging, pid 3625 - killed
> 030129 20:12:37 mysqld restarted
> 030129 20:12:37 mysqld ended
>
> just select on 2 columns in one table. 2 such table are marked
> as crashed. One is in Caenorhabditis_elegans_WS75, second is
> in Drosophila_melanogaster. [...]
> Info: Using database Clostridium_difficile_630 at @xx:3306
> [@xx:3306 Clostridium_difficile_630.contig_data]: 0 0
> contig710.0.0 Info: Using database Clostridium_perfringens_13
> at @xx:3306 [@xx:3306 Clostridium_perfringens_13.contig_data]:
> 0 0 NC_003042 Info: Using database
> Clostridium_thermocellum_ATCC27405 at @xx:3306 Error:
> [@xx:3306 Clostridium_thermocellum_ATCC27405.contig_data]:
> (execute failed): Got error 127 from table handler Info: Using
> database Corynebacterium_diphteriae_NCTC_13129 at @xx:3306
> [@xx:3306 Corynebacterium_diphteriae_NCTC_13129.contig_data]:
> 0 0 CDIP Info: Using database Corynebacterium_efficiens_YS314T
> at @xx:3306 [@xx:3306
> Corynebacterium_efficiens_YS314T.contig_data]: 0 0 NC_004369
> Info: Using database Corynebacterium_glutamicum at @xx:3306
> [@xx:3306 Corynebacterium_glutamicum.contig_data]: 0 0
> NC_003450 Info: Using database CpneumoniaeAR39 at @xx:3306
> [@xx:3306 CpneumoniaeAR39.contig_data]: 0 0 CpneumoniaeAR39
> Info: Using database Cpneumoniae_CWL029 at @xx:3306
> [@xx:3306 Cpneumoniae_CWL029.contig_data]: 0 0
> Cpneumoniae_CWL029 Info: Using database Ctrachomatis at
> @xx:3306
> [@xx:3306 Ctrachomatis.contig_data]: 0 0 Ctrachomatis
> Info: Using database Cyanidium_caldarium_chloroplast at
> @xx:3306 [@xx:3306
> Cyanidium_caldarium_chloroplast.contig_data]: 0 0 NC_001840
> Info: Using database Debaryomyces_hansenii_CBS_767 at @xx:3306
> Info: Using database Deinococcus_radiodurans_R1 at @xx:3306
> [@xx:3306 Deinococcus_radiodurans_R1.contig_data]: 0 0
> NC_000958 Info: Using database
> Desulfitobacterium_hafniense_DCB2 at @xx:3306 [@xx:3306
> Desulfitobacterium_hafniense_DCB2.contig_data]: 0 0
> 2351519_fasta_screen_Contig1000 Info: Using database
> Drosophila_melanogaster at @xx:3306 Error: [@xx:3306
> Drosophila_melanogaster.contig_data]: (execute failed): Can't
> open file: 'contig_data.MYD'. (errno: 145) Info: Using
> database Efaecalis at @xx:3306
> Warning: Efaecalis.contig_data does not exist, skipping
> command execution Info: Using database
> Encephalitozoon_cuniculi at @xx:3306
>
> After I've cancelled my strace process, I got back on terminal
> where the program ran:
>
> Error: [@xx:3306 Encephalitozoon_cuniculi.contig_data]:
> (execute failed): Lost connection to MySQL server during query
> Error: [@xx:3306 Erwinia_carotovora_atroseptica]: Can't
> connect to MySQL server on 'xx' (111) Error: Cannot use
> database Erwinia_carotovora_atroseptica on xx:3306. Skipping.
> Error: [@xx:3306 Escherichia_coli_CFT073]: Can't connect to
> MySQL server on 'xx' (111) Error: Cannot use database
> Escherichia_coli_CFT073 on xx:3306. Skipping. Error: [@xx:3306
> Escherichia_coli_K12]: Can't connect to MySQL server on 'xx'
> (111) Error: Cannot use database Escherichia_coli_K12 on
> xx:3306. Skipping. [...]
>
> I'd like to you to point you to lines 6180-6251 in the strace
> file, (http://pedant.gsf.de/strace.12202.log)
>
> 6238 [pid 3949] getcwd("/data/mysql", 4095) = 12
> 6239 [pid 3949]
> lstat64("/data/mysql/Caenorhabditis_elegans_WS75",
> {st_dev=makedev(58, 0), st_ino=7208961, st_mode=S_IFDIR|0700,
> st_nlink=2, st_uid=1005, st_gid=101, st_blksize=4096,
> st_blocks=8, st_size=4096, st_atime=2003/01/29-20:12:36,
> st_mtime=2003/01/27-18:32:19, st_ctime=2003/01/27-18:32:19}) =
> 0 6240 [pid 3949]
> lstat64("/data/mysql/Caenorhabditis_elegans_WS75/contig_data .M
>YI", {st_dev=makedev(58, 0), st_ino=7208990,
> st_mode=S_IFREG|0660, st_nlink=1, st_uid=1005, st_gid=101,
> st_blksize=4096, st_blocks=8, st_size=1024,
> st_atime=2003/01/29-20:10:14, st_mtime=2003/01/29-19:25:36,
> st_ctime=2003/01/29-19:25:36}) = 0 6241 [pid 3949]
> open("/data/mysql/Caenorhabditis_elegans_WS75/contig_data.MY I"
>, O_RDWR|O_LARGEFILE) = 84 6242 [pid 3949] read(84,
> "\376\376\7\1\0\7\2.\0\260\0d\0\374\0\5\0\0\5\0\10\2\0\0"... ,
> 24) = 24 6243 [pid 3949]
> readlink("./Caenorhabditis_elegans_WS75/contig_data.MYI",
> 0xbff5e7e4, 511) = -1 EINVAL (Invalid argument) 6244 [pid
> 3949]
> readlink("./Caenorhabditis_elegans_WS75/contig_data.MYD",
> 0xbff5e5e4, 511) = -1 EINVAL (Invalid argument) 6245 [pid
> 3949] _llseek(84, 0, [0], SEEK_SET) = 0 6246 [pid 3949]
> read(84,
> "\376\376\7\1\0\7\2.\0\260\0d\0\374\0\5\0\0\5\0\10\2\0\0"... ,
> 558) = 558 6247 [pid 3949] close(84) = 0
> 6248 [pid 3949] write(7, "3\0\0\1\377\370\3Can\'t open
> file: \'contig_"..., 55) = 55 6249 [pid 3949]
> sched_setscheduler(0xf6d, 0, 0xbff5f8c0) = -1 EINVAL (Invalid
> argument) 6250 [pid 3949] time([1043867556]) =
> 1043867556 6251 [pid 3949] read(7, "$\0\0\0", 4) = 4
>
>
> then lines 8694-8778 regarding Drosophila_melanogaster.
>
> The crash is here:
>
> 8882 [pid 3949] getcwd("/data/mysql", 4095) = 12
> 8883 [pid 3949]
> lstat64("/data/mysql/Encephalitozoon_cuniculi",
> {st_dev=makedev(58, 0), st_ino=12107777, st_mode=S_IFDIR|0700,
> st_nlink=2, st_uid=1005, st_gid=101, st_blksize=4096,
> st_blocks=8, st_size=4096, st_atime=2003/01/29-20:12:37,
> st_mtime=2003/01/28-05:49:35, st_ctime=2003/01/28-05:49:35}) =
> 0 8884 [pid 3949]
> lstat64("/data/mysql/Encephalitozoon_cuniculi/contig_data.MY I"
>, {st_dev=makedev(58, 0), st_ino=12107810,
> st_mode=S_IFREG|0660, st_nlink=1, st_uid=1005, st_gid=101,
> st_blksize=4096, st_blocks=16, st_size=7168,
> st_atime=2003/01/29-20:10:15, st_mtime=2003/01/28-05:46:35,
> st_ctime=2003/01/28-05:46:35}) = 0 8885 [pid 3949]
> open("/data/mysql/Encephalitozoon_cuniculi/contig_data.MYI",
> O_RDWR|O_LARGEFILE) = 138 8886 [pid 3949] read(138,
> "\376\376\7\1\0\7\2.\0\260\0d\0\374\0\5\0\0\5\0\10\2\0\0"... ,
> 24) = 24 8887 [pid 3949]
> readlink("./Encephalitozoon_cuniculi/contig_data.MYI",
> 0xbff5e7e4, 511) = -1 EINVAL (Invalid argument) 8888 [pid
> 3949] readlink("./Encephalitozoon_cuniculi/contig_data.MYD",
> 0xbff5e5e4, 511) = -1 EINVAL (Invalid argument) 8889 [pid
> 3949] _llseek(138, 0, [0], SEEK_SET) = 0 8890 [pid 3949]
> read(138,
> "\376\376\7\1\0\7\2.\0\260\0d\0\374\0\5\0\0\5\0\10\2\0\0"... ,
> 558) = 558 8891 [pid 3949]
> open("./Encephalitozoon_cuniculi/contig_data.MYD",
> O_RDWR|O_LARGEFILE) = 139 8892 [pid 3949] getpid()
> = 3949 8893 [pid 3949] read(139,
> "\376\376\10\1\226\0\0\0\26\324\0\0Q%\1\0005\0\0\0\0\0\0"... ,
> 32) = 32 8894 [pid 3949] old_mmap(0x594fa000, 4096,
> PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1,
> 0) = 0x594fa000 8895 [pid 3949] read(139, "\0\0\0A\200
> \301\0\340\200p@@\200N\20\16\0\f\20X\275\213"..., 118) = 118
> 8896 [pid 3949] old_mmap(0x594fb000, 4096,
> PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1,
> 0) = 0x594fb000 8897 [pid 3949] old_mmap(NULL, 2097152,
> PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) =
> 0x55354000 8898 [pid 3949] munmap(0x55354000, 704512) = 0
> 8899 [pid 3949] munmap(0x55500000, 344064) = 0
> 8900 [pid 3949] old_mmap(0x55400000, 77824,
> PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1,
> 0) = 0x55400000 8901 [pid 3949] time([1043867557]) =
> 1043867557 8902 [pid 3949] pread(138,
> "\0Z\0\0\0\0\0\0\0\226\0\0\0\1\0\0\347w\0\0\0\2\0\1\276"...,
> 1024, 1024) = 1024 8903 [pid 3949] _llseek(139, 150, [150],
> SEEK_SET) = 0 8904 [pid 3949] read(139,
> "\376\332\346\377>4\3O", 8) = 8 8905 [pid 3949]
> old_mmap(NULL, 270336, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x55354000 8906 [pid
> 3949] munmap(0x55400000, 1048576) = 0
> 8907 [pid 3949] --- SIGSEGV (Segmentation fault) ---
> 8908 <... poll resumed> [{fd=5, events=POLLIN,
> revents=POLLIN}], 1, 2000) = 1 8909 getppid()
> = 3623 8910 read(5,
> "\0\374\365\277\2\0\0\0\1\0\0\0\200\313<\10\1\0\0\0X\352"...,
> 148) = 148 8911 kill(3626, SIGRT_1) = 0
> 8912 --- SIGRT_1 (Real-time signal 1) ---
> 8913 sigreturn() = ? (mask now
> ~[TRAP KILL STOP]) 8914 kill(3623, SIGRT_1)
> = 0
> 8915 wait4(3626,
>
>
> As the file number was increasing, I guess the tables have
> been in the tablecache.
>
> Any suggestions what to put into my.cnf regarding debugging?:
>
> Which one?
> ##default is d:i:t:o,/tmp/mysqld.trace
> ##debug = d:i:t:o,/tmp/mysqld.trace
> ##debug = d,info,query,general:o,/tmp/mysqld.trace
> #debug = d,info,general,query
--
MySQL 2003 Users Conf. -> http://www.mysql.com/events/uc2003/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Peter Zaitsev
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
/_/ /_/\_, /___/\___\_\___/ Moscow, Russia
<___/ www.mysql.com
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13633@lists.mysql.com
To unsubscribe, e-mail
Re: crash with 4.0.9 on linux
am 29.01.2003 21:53:27 von mmokrejs
(gdb) c
Continuing.
Program received signal SIG32, Real-time event 32.
0x081ed939 in sigsuspend ()
(gdb) where
#0 0x081ed939 in sigsuspend ()
#1 0x081d79d9 in __pthread_wait_for_restart_signal ()
#2 0x081d7363 in pthread_create ()
#3 0x08084a09 in create_new_thread (thd=0x833dde8) at mysqld.cc:2462
#4 0x08084f9d in handle_connections_sockets (arg=0x0) at mysqld.cc:2691
#5 0x08084396 in main (argc=32, argv=0x8329e08) at mysqld.cc:2179
(gdb) bt
#0 0x081ed939 in sigsuspend ()
#1 0x081d79d9 in __pthread_wait_for_restart_signal ()
#2 0x081d7363 in pthread_create ()
#3 0x08084a09 in create_new_thread (thd=0x833dde8) at mysqld.cc:2462
#4 0x08084f9d in handle_connections_sockets (arg=0x0) at mysqld.cc:2691
#5 0x08084396 in main (argc=32, argv=0x8329e08) at mysqld.cc:2179
(gdb) n
Single stepping until exit from function sigsuspend,
which has no line number information.
0x081d79d9 in __pthread_wait_for_restart_signal ()
(gdb) n
Single stepping until exit from function __pthread_wait_for_restart_signal,
which has no line number information.
0x081d7363 in pthread_create ()
(gdb)
Single stepping until exit from function pthread_create,
which has no line number information.
create_new_thread (thd=0x833dde8) at mysqld.cc:2478
2478 in mysqld.cc
(gdb)
2481 in mysqld.cc
(gdb) mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=268431360
read_buffer_size=1044480
sort_buffer_size=2097116
max_used_connections=0
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 568936 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x833dde8
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbf5fea28, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
---- dirty trick here
$ ./resolve.sh
nm -n /usr/local/mysql/libexec/mysqld > ./symbols
/usr/local/mysql/bin/resolve_stack_dump -s ./symbols -n ./stack
0x80830db handle_segfault__Fi + 447
0x81d7d18 pthread_sighandler + 176
0x8205e83 memcpy + 51
0x819312f _mi_pack_get_block_info + 347
0x8191e4e _mi_read_pack_record + 114
0x8189e6e mi_rkey + 782
0x80e4a33 index_read_idx__9ha_myisamPcUiPCcUi16ha_rkey_function + 59
0x80b3216 join_read_const__FP13st_join_table + 102
0x80b2fdc join_read_const_table__FP13st_join_tableP11st_position + 184
0x80ab21e make_join_statistics__FP4JOINP13st_table_listP4ItemP16st_dyn amic_array + 2182
0x80a94c9 mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st _orderT4T3T4UlP13select_result + 2617
0x80a8a56 handle_select__FP3THDP6st_lexP13select_result + 102
0x808ecea mysql_execute_command__Fv + 1062
0x8092e66 mysql_parse__FP3THDPcUi + 214
0x808dcb8 dispatch_command__F19enum_server_commandP3THDPcUi + 1608
0x808d666 do_command__FP3THD + 310
0x808cd3e handle_one_connection__FPv + 694
0x81d5948 pthread_start_thread + 216
0x820f84a thread_start + 4
$
---- dirty trick end
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x83b5558 = select id, contig_data_id, contig_data_code from contig_data where id=0
thd->thread_id=1
Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 1 did to cause the crash. In some cases of really
bad corruption, the values shown above may be invalid.
The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
information that should help you find out what is causing the crash.
Program received signal SIG33, Real-time event 33.
create_new_thread (thd=0x833dde8) at mysqld.cc:2481
2481 in mysqld.cc
(gdb) bt
#0 create_new_thread (thd=0x833dde8) at mysqld.cc:2481
#1 0x08084f9d in handle_connections_sockets (arg=0x0) at mysqld.cc:2691
#2 0x08084396 in main (argc=32, argv=0x8329e08) at mysqld.cc:2179
(gdb) bt full
#0 create_new_thread (thd=0x833dde8) at mysqld.cc:2481
_db_func_ = 0x824aad0 "handle_connections_sockets"
_db_file_ = 0x824975c "mysqld.cc"
_db_level_ = 2
_db_framep_ = (char **) 0x824975c
net = (NET *) 0x833ddf4
#1 0x08084f9d in handle_connections_sockets (arg=0x0) at mysqld.cc:2691
sock = 8
new_sock = 13
error_count = 0
max_used_connection = 10
readFDs = {fds_bits = {256, 0 }}
clientFDs = {fds_bits = {768, 0 }}
thd = (THD *) 0x833dde8
cAddr = {sin_family = 2, sin_port = 26524, sin_addr = {s_addr = 16777343}, sin_zero = "\034?\035Ë·*\023À"}
ip_flags = 2
socket_flags = 2
flags = 137619232
vio_tmp = (st_vio *) 0x833e720
_db_func_ = 0x82ab485 "?func"
_db_file_ = 0x82ab48b "?file"
_db_level_ = 1
_db_framep_ = (char **) 0x40000000
#2 0x08084396 in main (argc=32, argv=0x8329e08) at mysqld.cc:2179
No locals.
(gdb)
Yes, the table is really compressed:
$ myisamchk -dvv /data/mysql/Erwinia_carotovora_atroseptica/contig_data.MYI
MyISAM file: /data/mysql/Erwinia_carotovora_atroseptica/contig_data.MYI
Record format: Compressed
Character set: latin1 (8)
File-version: 1
Creation time: 2003-01-25 15:38:56
Recover time: 2003-01-28 5:58:06
Status: checked,analyzed,optimized keys,sorted index pages
Checksum: 3502969102
Data records: 22 Deleted blocks: 0
Datafile parts: 22 Deleted data: 0
Datafile pointer (bytes): 4 Keyfile pointer (bytes): 2
Datafile length: 1258327 Keyfile length: 7168
Max datafile length: 4294967294 Max keyfile length: 67107839
Recordlength: 259872
table description:
Key Start Len Index Type Rec/key Root Blocksize
1 2 4 unique long 1 1024 1024
2 6 4 multip. long 1 2048 1024
3 10 100 multip. char packed stripped 1 3072 1024
4 110 100 multip. char packed stripped 1 4096 1024
5 210 255 multip. char packed stripped NULL 1 5120 2048
Field Start Length Nullpos Nullbit Type Huff tree Bits
1 1 1 1 9
2 2 4 zerofill(3) 1 9
3 6 4 zerofill(3) 1 9
4 10 100 no endspace 1 9
5 110 100 no endspace 1 9
6 210 255 1 1 no endspace 1 9
7 465 12 1 2 blob 2 2
8 477 100 no endspace 1 9
$
In another session, I've modified the my.cnf file to get more output.
mysqld was running under gdb,was in continue mode.
I've copied /dev/null to the trace file to make it empty.
Then I issued the select statement, mysqld crashed and I grabbed a snapshot
of the trace file:
Immediately after mysqld crashed I put the file here:
http://pedant.gsf.de/mysqld.trace-crash2
I hope I've saturated you with sufficient information. ;-)
I used in crashed reported in this particular email mysql-BK20021104-debug binaries.
--
Martin Mokrejs ,
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13634@lists.mysql.com
To unsubscribe, e-mail
Re: crash with 4.0.9 on linux
am 29.01.2003 22:18:05 von mmokrejs
And it works on another mysql server running linux. The only condition is,
that the client has to connect from localhost to get crash while reading
this table!
--
Martin Mokrejs ,
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13635@lists.mysql.com
To unsubscribe, e-mail
Re: crash with 4.0.9 on linux
am 29.01.2003 22:26:43 von mmokrejs
On Wed, 29 Jan 2003, Peter Zaitsev wrote:
> On Wednesday 29 January 2003 22:35, Martin MOKREJÅ wrote:
> > On Wed, 29 Jan 2003, Peter Zaitsev wrote:
>
> Did you mannage to
>
> -check and repair all the tables
> - start MySQL ensuring noone can possibly touch the same files
> - run your script
>
> and so run into table corruption ?
How-To-Repeat:
There is nothing to repair on this table. It just kills mysqld when client
connects from localhost. I could do extensive myisamchk, yes, but I put it
already on the web, so you can download and check yourself.
>
> If this is the case I would ask you to try to provide minimum
> test case (one table + small script would be the best)
> and upload it.
> This would help us to fix the bug.
>
> I'm not MyISAM low level specialist also it is really hard to
> work only with strace data.
On the second example Linux server with 4.0.9 too, it looks like this:
[pid 16185] read(7, "\3select id, contig_data_id, cont"..., 78) = 78
[pid 16185] rt_sigprocmask(SIG_BLOCK, ~[33], [HUP QUIT PIPE TERM TSTP RTMIN], 8) = 0
[pid 16185] rt_sigprocmask(SIG_SETMASK, [HUP QUIT PIPE TERM TSTP RTMIN], NULL, 8) = 0
[pid 16185] fcntl64(7, F_SETFL, O_RDWR|O_NONBLOCK) = 0
[pid 16185] time([1043874757]) = 1043874757
[pid 16185] sched_setscheduler(0x3f39, 0, 0xbff5f8c0) = -1 EINVAL (Invalid argument)
[pid 16185] time([1043874757]) = 1043874757
[pid 16185] _llseek(9, 177, [177], SEEK_SET) = 0
[pid 16185] read(9, "\376\343\360\377\262\302\3z", 8) = 8
[pid 16185] mremap(0x4a021000, 262144, 311296, MREMAP_MAYMOVE) = 0x4a063000
[pid 16185] --- SIGSEGV (Segmentation fault) ---
mysqld got signal 11;
So munmap() and also mremap()?
--
Martin Mokrejs ,
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13636@lists.mysql.com
To unsubscribe, e-mail
Re: crash with 4.0.9 on linux
am 29.01.2003 22:28:18 von mmokrejs
I have to resend this:
How-To-Repeat:
(gdb) c
Continuing.
Program received signal SIG32, Real-time event 32.
0x081ed939 in sigsuspend ()
(gdb) where
#0 0x081ed939 in sigsuspend ()
#1 0x081d79d9 in __pthread_wait_for_restart_signal ()
#2 0x081d7363 in pthread_create ()
#3 0x08084a09 in create_new_thread (thd=0x833dde8) at mysqld.cc:2462
#4 0x08084f9d in handle_connections_sockets (arg=0x0) at mysqld.cc:2691
#5 0x08084396 in main (argc=32, argv=0x8329e08) at mysqld.cc:2179
(gdb) bt
#0 0x081ed939 in sigsuspend ()
#1 0x081d79d9 in __pthread_wait_for_restart_signal ()
#2 0x081d7363 in pthread_create ()
#3 0x08084a09 in create_new_thread (thd=0x833dde8) at mysqld.cc:2462
#4 0x08084f9d in handle_connections_sockets (arg=0x0) at mysqld.cc:2691
#5 0x08084396 in main (argc=32, argv=0x8329e08) at mysqld.cc:2179
(gdb) n
Single stepping until exit from function sigsuspend,
which has no line number information.
0x081d79d9 in __pthread_wait_for_restart_signal ()
(gdb) n
Single stepping until exit from function __pthread_wait_for_restart_signal,
which has no line number information.
0x081d7363 in pthread_create ()
(gdb)
Single stepping until exit from function pthread_create,
which has no line number information.
create_new_thread (thd=0x833dde8) at mysqld.cc:2478
2478 in mysqld.cc
(gdb)
2481 in mysqld.cc
(gdb) mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=268431360
read_buffer_size=1044480
sort_buffer_size=2097116
max_used_connections=0
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 568936 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x833dde8
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbf5fea28, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
---- dirty trick here
$ ./resolve.sh
nm -n /usr/local/mysql/libexec/mysqld > ./symbols
/usr/local/mysql/bin/resolve_stack_dump -s ./symbols -n ./stack
0x80830db handle_segfault__Fi + 447
0x81d7d18 pthread_sighandler + 176
0x8205e83 memcpy + 51
0x819312f _mi_pack_get_block_info + 347
0x8191e4e _mi_read_pack_record + 114
0x8189e6e mi_rkey + 782
0x80e4a33 index_read_idx__9ha_myisamPcUiPCcUi16ha_rkey_function + 59
0x80b3216 join_read_const__FP13st_join_table + 102
0x80b2fdc join_read_const_table__FP13st_join_tableP11st_position + 184
0x80ab21e make_join_statistics__FP4JOINP13st_table_listP4ItemP16st_dyn amic_array + 2182
0x80a94c9 mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st _orderT4T3T4UlP13select_result + 2617
0x80a8a56 handle_select__FP3THDP6st_lexP13select_result + 102
0x808ecea mysql_execute_command__Fv + 1062
0x8092e66 mysql_parse__FP3THDPcUi + 214
0x808dcb8 dispatch_command__F19enum_server_commandP3THDPcUi + 1608
0x808d666 do_command__FP3THD + 310
0x808cd3e handle_one_connection__FPv + 694
0x81d5948 pthread_start_thread + 216
0x820f84a thread_start + 4
$
---- dirty trick end
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x83b5558 = select id, contig_data_id, contig_data_code from contig_data where id=0
thd->thread_id=1
Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 1 did to cause the crash. In some cases of really
bad corruption, the values shown above may be invalid.
The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
information that should help you find out what is causing the crash.
Program received signal SIG33, Real-time event 33.
create_new_thread (thd=0x833dde8) at mysqld.cc:2481
2481 in mysqld.cc
(gdb) bt
#0 create_new_thread (thd=0x833dde8) at mysqld.cc:2481
#1 0x08084f9d in handle_connections_sockets (arg=0x0) at mysqld.cc:2691
#2 0x08084396 in main (argc=32, argv=0x8329e08) at mysqld.cc:2179
(gdb) bt full
#0 create_new_thread (thd=0x833dde8) at mysqld.cc:2481
_db_func_ = 0x824aad0 "handle_connections_sockets"
_db_file_ = 0x824975c "mysqld.cc"
_db_level_ = 2
_db_framep_ = (char **) 0x824975c
net = (NET *) 0x833ddf4
#1 0x08084f9d in handle_connections_sockets (arg=0x0) at mysqld.cc:2691
sock = 8
new_sock = 13
error_count = 0
max_used_connection = 10
readFDs = {fds_bits = {256, 0 }}
clientFDs = {fds_bits = {768, 0 }}
thd = (THD *) 0x833dde8
cAddr = {sin_family = 2, sin_port = 26524, sin_addr = {s_addr = 16777343}, sin_zero = "\034?\035Ë·*\023À"}
ip_flags = 2
socket_flags = 2
flags = 137619232
vio_tmp = (st_vio *) 0x833e720
_db_func_ = 0x82ab485 "?func"
_db_file_ = 0x82ab48b "?file"
_db_level_ = 1
_db_framep_ = (char **) 0x40000000
#2 0x08084396 in main (argc=32, argv=0x8329e08) at mysqld.cc:2179
No locals.
(gdb)
Yes, the table is really compressed:
$ myisamchk -dvv /data/mysql/Erwinia_carotovora_atroseptica/contig_data.MYI
MyISAM file: /data/mysql/Erwinia_carotovora_atroseptica/contig_data.MYI
Record format: Compressed
Character set: latin1 (8)
File-version: 1
Creation time: 2003-01-25 15:38:56
Recover time: 2003-01-28 5:58:06
Status: checked,analyzed,optimized keys,sorted index pages
Checksum: 3502969102
Data records: 22 Deleted blocks: 0
Datafile parts: 22 Deleted data: 0
Datafile pointer (bytes): 4 Keyfile pointer (bytes): 2
Datafile length: 1258327 Keyfile length: 7168
Max datafile length: 4294967294 Max keyfile length: 67107839
Recordlength: 259872
table description:
Key Start Len Index Type Rec/key Root Blocksize
1 2 4 unique long 1 1024 1024
2 6 4 multip. long 1 2048 1024
3 10 100 multip. char packed stripped 1 3072 1024
4 110 100 multip. char packed stripped 1 4096 1024
5 210 255 multip. char packed stripped NULL 1 5120 2048
Field Start Length Nullpos Nullbit Type Huff tree Bits
1 1 1 1 9
2 2 4 zerofill(3) 1 9
3 6 4 zerofill(3) 1 9
4 10 100 no endspace 1 9
5 110 100 no endspace 1 9
6 210 255 1 1 no endspace 1 9
7 465 12 1 2 blob 2 2
8 477 100 no endspace 1 9
$
In another session, I've modified the my.cnf file to get more output.
mysqld was running under gdb,was in continue mode.
I've copied /dev/null to the trace file to make it empty.
Then I issued the select statement, mysqld crashed and I grabbed a snapshot
of the trace file:
Immediately after mysqld crashed I put the file here:
http://pedant.gsf.de/mysqld.trace-crash2
I hope I've saturated you with sufficient information. ;-)
I used in crashed reported in this particular email mysql-BK20021104-debug binaries.
--
Martin Mokrejs ,
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13637@lists.mysql.com
To unsubscribe, e-mail
Re: crash with 4.0.9 on linux
am 29.01.2003 22:28:53 von mmokrejs
How-To-Repeat:
Hi,
another attempt with older mysql version from bitkeeper with debug
enabled:
http://pedant.gsf.de/mysqld.trace-crash.out - output of my script
http://pedant.gsf.de/mysqld.trace-crash - trace file, unfortunately
it does not list the database names, so
I'm not sure how can you find the relevant rows.
http://pedant.gsf.de/Erwinia_carotovora_atroseptica.tgz
- the table causing crashes
--
Martin Mokrejs ,
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13638@lists.mysql.com
To unsubscribe, e-mail
Re: crash with 4.0.9 on linux
am 30.01.2003 14:31:20 von Sinisa Milivojevic
=?iso-8859-2?Q?Martin_MOKREJ=A9?= writes:
> Hi,
> another attempt with older mysql version from bitkeeper with debug
> enabled:
>
> http://pedant.gsf.de/mysqld.trace-crash.out - output of my script
> http://pedant.gsf.de/mysqld.trace-crash - trace file, unfortunately
> it does not list the database names, so
> I'm not sure how can you find the relevant rows.
>
> http://pedant.gsf.de/Erwinia_carotovora_atroseptica.tgz
> - the table causing crashes
>
OK,
I have taken a deep look into your table.
Diagnosis is actually quite complex.
Your table was crashed while it was attempted to be compresseed,
i.e. packed, with myisampack or similar.
Therefore, it is marked as read-only, while it's indices are
corrupted.
This can crash MySQL, while it prevents normal repair.
Cure is however simple.
myisamchk --safe-recover --force ... fixes a problem.
All you have to do more is to re-start MySQL server.
--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ www.mysql.com
Join MySQL Users Conference and Expo:
http://www.mysql.com/events/uc2003/
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13640@lists.mysql.com
To unsubscribe, e-mail
Re: crash with 4.0.9 on linux
am 30.01.2003 15:11:23 von mmokrejs
On Thu, 30 Jan 2003, Sinisa Milivojevic wrote:
> =?iso-8859-2?Q?Martin_MOKREJ=A9?= writes:
> > Hi,
> > another attempt with older mysql version from bitkeeper with debug
> > enabled:
> >
> > http://pedant.gsf.de/mysqld.trace-crash.out - output of my script
> > http://pedant.gsf.de/mysqld.trace-crash - trace file, unfortunately
> > it does not list the database names, so
> > I'm not sure how can you find the relevant rows.
> >
> > http://pedant.gsf.de/Erwinia_carotovora_atroseptica.tgz
> > - the table causing crashes
> >
>
> OK,
>
> I have taken a deep look into your table.
>
> Diagnosis is actually quite complex.
>
> Your table was crashed while it was attempted to be compresseed,
> i.e. packed, with myisampack or similar.
>
> Therefore, it is marked as read-only, while it's indices are
> corrupted.
Sorry, I don't get it. "myisamchk -e" doesn't report any errors on that
compressed table. Compressed MyISAM tables are always readonly, but where
do you see the "mark" read-only? "myisamchk -dvv" doesn't show anything
wrong:
Status: checked,analyzed,optimized keys,sorted index pages
> This can crash MySQL, while it prevents normal repair.
If I'll understand the above, then I'll believe. Cureently, I do not use
myisam-recover = BACKUP,FORCE
as all aborted connection render tables opened by one client and that
immediately makes mysqld to check the whole table. It just costs too much
in our setup. But I guess you did not expect us to have these turned on to
have the "normal repair".
> Cure is however simple.
>
> myisamchk --safe-recover --force ... fixes a problem.
>
> All you have to do more is to re-start MySQL server.
Yes, that worked, but as I've created that table few days ago by importing
mysql dump file, compressed and have not seen any errors, am a bit
suspicious. Any, does mysqld have to crash on it? ;)
Thanks!
--
Martin Mokrejs ,
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13641@lists.mysql.com
To unsubscribe, e-mail
Re: crash with 4.0.9 on linux
am 30.01.2003 16:27:03 von Sinisa Milivojevic
=3D?iso-8859-2?Q?Martin_MOKREJ=3DA9?=3D writes:
> On Thu, 30 Jan 2003, Sinisa Milivojevic wrote:
>=20
>=20
> Yes, that worked, but as I've created that table few days ago by impo=
rting
> mysql dump file, compressed and have not seen any errors, am a bit
> suspicious. Any, does mysqld have to crash on it? ;)
>=20
> Thanks!
> --=20
> Martin Mokrejs ,
> PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
> MIPS / Institute for Bioinformatics
> GSF - National Research Center for Environment and Health
> Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
> tel.: +49-89-3187 3683 , fax:=A0+49-89-3187 3585
>=20
We managed to reproduce some of the behaviour, so it is promising ...=20=
--=20
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ www.mysql.com
Join MySQL Users Conference and Expo:
http://www.mysql.com/events/uc2003/
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13642@lists.mysql.com
To unsubscribe, e-mail
Re: crash with 4.0.9 on linux
am 30.01.2003 21:19:04 von Sinisa Milivojevic
=3D?iso-8859-2?Q?Martin_MOKREJ=3DA9?=3D writes:
> On Thu, 30 Jan 2003, Sinisa Milivojevic wrote:
>=20
> Sorry, I don't get it. "myisamchk -e" doesn't report any errors on th=
at
> compressed table. Compressed MyISAM tables are always readonly, but w=
here
> do you see the "mark" read-only? "myisamchk -dvv" doesn't show anythi=
ng
> wrong:
>=20
> Status: checked,analyzed,optimized keys,sorted index pag=
es
>=20
[skip]
>=20
> Yes, that worked, but as I've created that table few days ago by impo=
rting
> mysql dump file, compressed and have not seen any errors, am a bit
> suspicious. Any, does mysqld have to crash on it? ;)
>=20
> Thanks!
> --=20
> Martin Mokrejs ,
> PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
> MIPS / Institute for Bioinformatics
> GSF - National Research Center for Environment and Health
> Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
> tel.: +49-89-3187 3683 , fax:=A0+49-89-3187 3585
>=20
Thank you for your bug report.
It helped us solve a bug.
A fix will come in the next MySQL 4.0 release.
--=20
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ www.mysql.com
Join MySQL Users Conference and Expo:
http://www.mysql.com/events/uc2003/
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13644@lists.mysql.com
To unsubscribe, e-mail
Re: crash with 4.0.9 on linux
am 31.01.2003 00:10:42 von mmokrejs
On Thu, 30 Jan 2003, Sinisa Milivojevic wrote:
Hi Sinisa!
> Thank you for your bug report.
>
> It helped us solve a bug.
>
> A fix will come in the next MySQL 4.0 release.
Thanks for your patience, may I know little bit more of the details.
I expected the crash itself is fixed, will be also the myisamchk
be fixed (if it really made the table somehow broken but did not
realise it itself)? Third, should the problem with error 127
go away too?
--
Martin Mokrejs ,
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13645@lists.mysql.com
To unsubscribe, e-mail
Re: crash with 4.0.9 on linux
am 31.01.2003 13:57:55 von Sinisa Milivojevic
=3D?iso-8859-2?Q?Martin_MOKREJ=3DA9?=3D writes:
> On Thu, 30 Jan 2003, Sinisa Milivojevic wrote:
>=20
> Hi Sinisa!
> Thanks for your patience, may I know little bit more of the details.
> I expected the crash itself is fixed, will be also the myisamchk
> be fixed (if it really made the table somehow broken but did not
> realise it itself)? Third, should the problem with error 127
> go away too?
>=20
> --=20
> Martin Mokrejs ,
> PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
> MIPS / Institute for Bioinformatics
> GSF - National Research Center for Environment and Health
> Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
> tel.: +49-89-3187 3683 , fax:=A0+49-89-3187 3585
>=20
First of all, here is a patch:
-- 1.112/myisam/mi_check.c=09Sun Jan 26 12:27:26 2003
+++ 1.113/myisam/mi_check.c=09Thu Jan 30 19:34:16 2003
@@ -920,7 +920,7 @@
=09goto err;
start_recpos=3Dpos;
splits++;
- VOID(_mi_pack_get_block_info(info,&block_info, -1, start_recpos,=
NullS));
+ VOID(_mi_pack_get_block_info(info,&block_info, -1, start_recpos)=
);
pos=3Dblock_info.filepos+block_info.rec_len;
if (block_info.rec_len < (uint) info->s->min_pack_length ||
=09 block_info.rec_len > (uint) info->s->max_pack_length)
@@ -2891,7 +2891,7 @@
=09DBUG_RETURN(1); /* Something wrong with data */
}
sort_param->start_recpos=3Dsort_param->pos;
- if (_mi_pack_get_block_info(info,&block_info,-1,sort_param->pos ,=
NullS))
+ if (_mi_pack_get_block_info(info,&block_info,-1,sort_param->pos )=
)
=09DBUG_RETURN(-1);
if (!block_info.rec_len &&
=09 sort_param->pos + MEMMAP_EXTRA_MARGIN ==
--- 1.18/myisam/mi_packrec.c=09Fri Jul 26 14:42:49 2002
+++ 1.19/myisam/mi_packrec.c=09Thu Jan 30 19:34:16 2003
@@ -416,8 +416,7 @@
DBUG_RETURN(-1); =09/* _search() didn't find record */
=20
file=3Dinfo->dfile;
- if (_mi_pack_get_block_info(info, &block_info, file, filepos,
- =09 info->rec_buff))
+ if (_mi_pack_get_block_info(info, &block_info, file, filepos))
goto err;
if (my_read(file,(byte*) info->rec_buff + block_info.offset ,
=09 block_info.rec_len - block_info.offset, MYF(MY_NABP)))
@@ -963,11 +962,10 @@
if (_mi_read_cache(&info->rec_cache,(byte*) block_info.header,file=
pos,
share->pack.ref_length, skip_deleted_blocks))
goto err;
- b_type=3D_mi_pack_get_block_info(info,&block_info,-1, filepos, Nul=
lS);
+ b_type=3D_mi_pack_get_block_info(info,&block_info,-1, filepos);
}
else
- b_type=3D_mi_pack_get_block_info(info,&block_info,info->dfil e,file=
pos,
- info->rec_buff);
+ b_type=3D_mi_pack_get_block_info(info,&block_info,info->dfil e,file=
pos);
if (b_type)
goto err; =09/* Error code is already set */
#ifndef DBUG_OFF
@@ -1007,7 +1005,7 @@
=09/* Read and process header from a huff-record-file */
=20
uint _mi_pack_get_block_info(MI_INFO *myisam, MI_BLOCK_INFO *info, Fil=
e file,
- =09 my_off_t filepos, char *rec_buff)
+ =09 my_off_t filepos)
{
uchar *header=3Dinfo->header;
uint head_length,ref_length;
@@ -1067,7 +1065,7 @@
if (file > 0)
{
info->offset=3Dmin(info->rec_len, ref_length - head_length);
- memcpy(rec_buff, header+head_length, info->offset);
+ memcpy(myisam->rec_buff, header+head_length, info->offset);
}
return 0;
}
--- 1.55/myisam/myisamdef.h=09Thu Jan 9 01:19:11 2003
+++ 1.56/myisam/myisamdef.h=09Thu Jan 30 19:34:16 2003
@@ -608,8 +608,7 @@
=20
extern uint _mi_get_block_info(MI_BLOCK_INFO *,File, my_off_t);
extern uint _mi_rec_pack(MI_INFO *info,byte *to,const byte *from);
-extern uint _mi_pack_get_block_info(MI_INFO *mysql, MI_BLOCK_INFO *, F=
ile,
- my_off_t, char *rec_buf);
+extern uint _mi_pack_get_block_info(MI_INFO *, MI_BLOCK_INFO *, File, =
my_off_t);
extern void _my_store_blob_length(byte *pos,uint pack_length,uint leng=
th);
extern void _myisam_log(enum myisam_log_commands command,MI_INFO *info=
,
const byte *buffert,uint length);
As you can see a bug was in some of MyISAM functions, so all programs
using those functions, inluding myisamchk and MySQL server will be
fixed.=20
=20
--=20
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ www.mysql.com
Join MySQL Users Conference and Expo:
http://www.mysql.com/events/uc2003/
------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail bugs-thread13647@lists.mysql.com
To unsubscribe, e-mail