Изпечатай

[senser]

Здравейте,

Имам инсталиран MySQL 5.0.26 на следната машина:
Gentoo Linux 2.6.17-hardened-r1 #1 Wed Nov 22 11:12:22 EET 2006 i686 AMD Duron™ Processor AuthenticAMD GNU/Linux
всичко е компилирано с i686-pc-linux-gnu-3.4.6-hardenednopiessp
glibc-2.3.6-r5 hardened & nptl

Това са и опциите с които е компилирано:
CFLAGS="-mtune=athlon-tbird -O3 -pipe -fomit-frame-pointerm -fstack-protector"

Сега към проблема:
тестова база world, в която има таблица City с 4079 записа
сторидж енджин е MyISAM
при опит за добавяне на индекс към някоя от колоните на таблицата MySQL-a крашва

Примерен код

mysql> alter table City add index (Population); ERROR 2013 (HY000): Lost connection to MySQL server during query mysql>

ето какво излиза в лога:

Примерен код

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=16777216 read_buffer_size=258048 max_used_connections=1 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 = 92783 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8bd2918 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... frame pointer is NULL, did you compile with -fomit-frame-pointer? Aborting backtrace! Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x8be3540 = alter table City add index (Population) thd->thread_id=1 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash.

Намерих подобни проблеми по форумите и решение с изключване на поддръжката на BerkleyDB при компилиране на MySQL, но при мен това не помогна. Увеличаването на буферите също не дава резулта.

Интересното е, че ако се ползва InnoDB за сторидж енджин няма проблем.

Подозирам, че проблема идва от glibc, но ......

[senser]

гледам из форумите че подобни проблеми има с таблици от 4.* версиите на MySQL
само че аз дори и когато създам нова таблица се получава същия краш
явно има отношение към достъпването на паметта защото при елементарна таблица с 2 колони и 50 записа добавянето на индекс не предизвиква проблем, но увелича ли записите на 100 и умира '>

[senser]

никой ли няма идея къде да търся проблема  '>

[CTEHATA]

Цитат (senser @ Ноември 24 2006,11:14)

никой ли няма идея къде да търся проблема  '>

Провери таблицата за грешки и пиши. Рядък, но гаден проблем. Дано помогнах '>

[senser]

Цитат (CTEHATA @ Ноември 24 2006,12:24)

Цитат (senser @ Ноември 24 2006,11:14) никой ли няма идея къде да търся проблема  '> Провери таблицата за грешки и пиши. Рядък, но гаден проблем. Дано помогнах '>

не е там проблема, но има връзка

в смисъл, че проблема с добавянето на индекс не е в таблицата, защото се получава и при нова таблица в нова база данни, а казвам че има връзка защото при опит за добавяне на индекс, когато сервера крашва и таблицата естествено се маркира като "лоша"
но при опит след това да я фиксна се получава грешка:

Примерен код

myisamchk -vr temp.MYI - recovering (with sort) MyISAM-table 'temp.MYI' Data records: 198 - Fixing index 1 Segmentation fault