Hello Michael,
Thursday, June 28, 2001, 1:52:09 PM, you wrote:
MW> Hi!
>>>>>> "Peter" == Peter Zaitsev <[EMAIL PROTECTED]> writes:
Peter>> Hello monty,
Peter>> after upgrading mysql 3.23.36 to mysql 3.23.29 I started to get a
Peter>> core dumps, therefore I can't get why it's crashing.
Peter>> Of couse I'll try to roll it back but do you have any ideas:
Peter>> 0x806c4c4 handle_segfault__Fi + 428
Peter>> 0x822a2e8 pthread_sighandler + 168
Peter>> 0x82559df chunk_alloc + 255
Peter>> 0x8255791 malloc + 209
Peter>> 0x821487e my_malloc + 30
Peter>> 0x8068236 my_net_init__FP6st_netP6st_vio + 30
Peter>> 0x806de12 handle_connections_sockets__FPv + 870
Peter>> 0x806d5f5 main + 3101
Peter>> 0x823d853 __libc_start_main + 179
Peter>> 0x8048101 _start + 33
Peter>> -------------------
Peter>> Other one:
Peter>> 0x806c4c4 handle_segfault__Fi + 428
Peter>> 0x822a2e8 pthread_sighandler + 168
Peter>> 0x82563af chunk_free + 591
Peter>> 0x8256123 free + 147
Peter>> 0x8214906 my_no_flags_free + 22
Peter>> 0x8214f18 free_root + 84
Peter>> 0x80aa083 test_quick_select__10SQL_SELECTUlUlUlb + 1551
Peter>> 0x808b3eb
make_join_statistics__FP4JOINP13st_table_listP4ItemP16st_dynamic_arrayRt4List1Z15Item_func_match
+ 2595
Peter>> 0x8089a5d
mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemRt4List1Z15Item_func_matchP8st_orderT5T3T5UiP13select_result
+ 1837
Peter>> 0x807307a mysql_execute_command__Fv + 758
Peter>> 0x8077024 mysql_parse__FP3THDPcUi + 216
Peter>> 0x8072304 do_command__FP3THD + 1436
Peter>> 0x80716f7 handle_one_connection__FPv + 655
Peter>> It seems like there are some problems with memory managent happening ?
MW> This looks serious.
MW> It's also quite strange as MySQL 3.23.39 has been quite stable for us.
MW> It has also been out almost 2 weeks without any bug reports for this
MW> and we know that lots of users are using this.
The even worse is the following situation:
I started to often get the followings in a log file:
010628 13:49:28 Aborted connection 627619 to db: 'counter' user: 'titan' host:
`pan.local' (Got an error reading communication packets)
010628 13:49:35 read_key: Got error 134 when reading table './counter/counterlayers'
010628 13:49:35 read_key: Got error 134 when reading table './counter/counterlayers'
All the times for the same table. The strange thing is - I do ONLY
selects and updates for this table, therefor I got the followings then
I'm trying to check and repair it.
mysql> check table counter.counterlayers;
+-----------------------+-------+----------+-------------------------------------------------------+
| Table | Op | Msg_type | Msg_text
| |
+-----------------------+-------+----------+-------------------------------------------------------+
| counter.counterlayers | check | error | Record-count is not ok; is 166853
|Should be: 166912 |
| counter.counterlayers | check | warning | Found 59 deleted blocks Should be:
|0 |
| counter.counterlayers | check | error | Corrupt
| |
+-----------------------+-------+----------+-------------------------------------------------------+
3 rows in set (0.49 sec)
mysql> repair table counter.counterlayers;
+-----------------------+--------+----------+----------------------------------------------+
| Table | Op | Msg_type | Msg_text
| |
+-----------------------+--------+----------+----------------------------------------------+
| counter.counterlayers | repair | warning | Number of rows changed from 166912 to
|166853 |
| counter.counterlayers | repair | status | OK
| |
+-----------------------+--------+----------+----------------------------------------------+
2 rows in set (1.94 sec)
As you see 59 rows are deleted therefore noone did it.
MW> Can you repeat this by issuing the query again ?
MW> Have you upgraded anything else on your server like kernel or glibc ?
Well. Yes. I've upgraded kernel on this machine to the latest one -
2.2.19, therefore it works for months on many machines.
MW> Have you compiled MySQL yourself ?
Yes. I always do this for more than a year now. Parameters have not
changed from default one. and the funny thing is - this executable is
NFS shared over more then 25 machines and works without any problems.
MW> Have you patched glibc to have a small stack ?
No I did not.
MW> Are you testing some new feature, like test search ?
No. I do not. BDB and INNODB are complied in but disabled on this
machine.
MW> Have you changed your queries in any way ?
No.
MW> Regards,
MW> Monty
MW> PS: Please email your problems to [EMAIL PROTECTED], with a CC to me.
MW> I will go on a conference trip to Australia and will not have
MW> reliable email access for almost a month.
OK. I see.
--
Best regards,
Peter mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
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 <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
