[devel] python-module-MySQLdb требует пересборки?

[devel] python-module-MySQLdb требует пересборки?

[Eugene Vlasov]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

Добрый день.

После обновления MySQL до 5.0.24-alt1 у меня отказалось работать одно
приложение, использующее python-module-MySQLdb (1.2.0-alt0.1).
Пересборка последнего вроде решила проблему. Это у кого-то
воспроизводится? Возможно и другие приложения собранные с MySQL
сломались?

-- 
WBR, Eugene Vlasov        mailto:eugvv at altlinux.ru
                          JID: eugvv@jabber.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [devel] python-module-MySQLdb требует пересборки?

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

Hi Eugene!

Saturday 26, at 03:22:49 PM you wrote:

> Добрый день.
> 
> После обновления MySQL до 5.0.24-alt1 у меня отказалось работать одно
> приложение, использующее python-module-MySQLdb (1.2.0-alt0.1).
> Пересборка последнего вроде решила проблему. Это у кого-то
> воспроизводится? Возможно и другие приложения собранные с MySQL
> сломались?
возможно. Я вообще-то сразу говорил, когда выкладывал MySQL 5.0.x, чтобы
мантейнеры проверили работоспособность своих приложений, зависящих от
libMySQL. Видимо, данный призыв никто не воспринял как руководство к
действию.

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] python-module-MySQLdb требует пересборки?

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 4826 bytes --]

On Sat, Aug 26, 2006 at 03:22:49PM +0600, Eugene Vlasov wrote:
> Добрый день.
> 
> После обновления MySQL до 5.0.24-alt1 у меня отказалось работать одно
> приложение, использующее python-module-MySQLdb (1.2.0-alt0.1).
> Пересборка последнего вроде решила проблему. Это у кого-то
> воспроизводится? Возможно и другие приложения собранные с MySQL
> сломались?

Так точно.  Проверил perl-DBD-mysql.  Пересборка и make test проходят
нормально.  Но если в make test подсунуть ранее собранный модуль, то
драйвер виснет/ падает /проваливает тесты.

at@localhost ~build/DBD-mysql-3.0006 8 $ make
...
/usr/bin/perl5.8.8 myld gcc  -shared -Wl,-O1 -L/usr/local/lib dbdimp.o mysql.o  -o blib/arch/auto/DBD/mysql/mysql.so    \
           -L/usr/lib -lmysqlclient -lz -lcrypt -lnsl -lm -L/usr/lib -lssl -lcrypto     \

chmod 755 blib/arch/auto/DBD/mysql/mysql.so
cp mysql.bs blib/arch/auto/DBD/mysql/mysql.bs
chmod 644 blib/arch/auto/DBD/mysql/mysql.bs
Manifying blib/man3/DBD::mysql.3
Manifying blib/man3/DBD::mysql::INSTALL.3
Manifying blib/man3/Mysql.3
Manifying blib/man3/Bundle::DBD::mysql.3
at@localhost ~build/DBD-mysql-3.0006 8 $ make test
PERL_DL_NONLAZY=1 /usr/bin/perl5.8.8 "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00base.............ok
t/10dsnlist..........ok
t/20createdrop.......ok
t/30insertfetch......ok
t/35limit............ok
t/35prepare..........ok
t/40bindparam........ok
t/40blobs............ok
t/40listfields.......ok
t/40nulls............ok
t/40numrows..........ok
t/41bindparam........ok
t/41blobs_prepare....ok
t/42bindparam........ok
t/50chopblanks.......ok
t/50commit...........ok
t/60leaks............skipped
        all skipped: $ENV{SLOW_TESTS} is not set or Proc::ProcessTable not installed
t/dbdadmin...........ok
t/insertid...........ok
t/param_values.......ok
t/prepare_noerror....ok
t/texecute...........ok
All tests successful, 1 test skipped.
Files=22, Tests=434, 22 wallclock secs ( 1.28 cusr +  0.10 csys =  1.38 CPU)
at@localhost ~build/DBD-mysql-3.0006 8 $ rm -rf blib
at@localhost ~build/DBD-mysql-3.0006 8 $ perl -MExtUtils::Command::MM -e test_harness */*.t
t/00base.............ok                                                      
t/10dsnlist..........dubious                                                 
        Test returned status 0 (wstat 11, 0xb)
t/20createdrop.......ok                                                      
t/30insertfetch......ok                                                      
t/35limit............ok                                                      
t/35prepare..........ok                                                      
t/40bindparam........ok                                                      
t/40blobs............ok                                                      
t/40listfields.......ok                                                      
t/40nulls............ok                                                      
t/40numrows..........ok                                                      
t/41bindparam........ok                                                      
t/41blobs_prepare....ok                                                      
t/42bindparam........ok                                                      
t/50chopblanks.......ok                                                      
t/50commit...........Transactions not supported by database at t/50commit.t line 101.
t/50commit...........dubious                                                 
        Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 5-30
        Failed 26/30 tests, 13.33% okay
t/60leaks............skipped
        all skipped: $ENV{SLOW_TESTS} is not set or Proc::ProcessTable not installed 
t/dbdadmin...........dubious                                                 
        Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 2-21
        Failed 20/21 tests, 4.76% okay
t/insertid...........ok                                                      
t/param_values.......ok                                                      
t/prepare_noerror....ok                                                      
t/texecute...........ok                                                      
Failed Test   Stat Wstat Total Fail  List of Failed
-------------------------------------------------------------------------------
t/10dsnlist.t    0    11    ??   ??  ??
t/50commit.t   255 65280    30   52  5-30
t/dbdadmin.t     0    11    21   40  2-21
1 test skipped.
Failed 3/22 test scripts. 46/425 subtests failed.
Files=22, Tests=425,  7 wallclock secs ( 1.25 cusr +  0.09 csys =  1.34 CPU)
Failed 3/22 test programs. 46/425 subtests failed.
$

wstat 11 -- это SEGV.
Сволочи.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] python-module-MySQLdb требует пересборки?

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

Hi Alexey!

Saturday 26, at 05:57:29 PM you wrote:

> On Sat, Aug 26, 2006 at 03:22:49PM +0600, Eugene Vlasov wrote:
> > Добрый день.
> > 
> > После обновления MySQL до 5.0.24-alt1 у меня отказалось работать одно
> > приложение, использующее python-module-MySQLdb (1.2.0-alt0.1).
> > Пересборка последнего вроде решила проблему. Это у кого-то
> > воспроизводится? Возможно и другие приложения собранные с MySQL
> > сломались?
> 
> Так точно.  Проверил perl-DBD-mysql.  Пересборка и make test проходят
> нормально.  Но если в make test подсунуть ранее собранный модуль, то
> драйвер виснет/ падает /проваливает тесты.
> 
интересно, а что скажет abi-drift?

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] python-module-MySQLdb требует пересборки?

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

On Sat, Aug 26, 2006 at 06:09:44PM +0400, Konstantin A. Lepikhov wrote:
> Hi Alexey!
> 
> Saturday 26, at 05:57:29 PM you wrote:
> 
> > On Sat, Aug 26, 2006 at 03:22:49PM +0600, Eugene Vlasov wrote:
> > > Добрый день.
> > > 
> > > После обновления MySQL до 5.0.24-alt1 у меня отказалось работать одно
> > > приложение, использующее python-module-MySQLdb (1.2.0-alt0.1).
> > > Пересборка последнего вроде решила проблему. Это у кого-то
> > > воспроизводится? Возможно и другие приложения собранные с MySQL
> > > сломались?
> > 
> > Так точно.  Проверил perl-DBD-mysql.  Пересборка и make test проходят
> > нормально.  Но если в make test подсунуть ранее собранный модуль, то
> > драйвер виснет/ падает /проваливает тесты.
> > 
> интересно, а что скажет abi-drift?

Он вроде заглох послденее время.  message size >1M.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] python-module-MySQLdb требует пересборки?

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

On Sat, Aug 26, 2006 at 06:17:31PM +0400, Alexey Tourbin wrote:
> > интересно, а что скажет abi-drift?
> Он вроде заглох послденее время.  message size >1M.

Впрочем, abi_drift проверят только разрешимость символов.  То есть с
abi_drift можно спрашивать, когда приложение падает по undefined symbol.
Здесь что-то более тонкое.  Я попробовал в gdb расковырять но там
сплошные callback'и, в общем боюсь что мне слабо такое расковырять.
Но попробую ещё...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] python-module-MySQLdb требует пересборки?

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

Eugene Vlasov wrote:
> Добрый день.
> 
> После обновления MySQL до 5.0.24-alt1 у меня отказалось работать одно
> приложение, использующее python-module-MySQLdb (1.2.0-alt0.1).
> Пересборка последнего вроде решила проблему. Это у кого-то
> воспроизводится? Возможно и другие приложения собранные с MySQL
> сломались?

Насколько я помню свои разборки с каким-то криво настроенным хостингом,
во времена 4.1.x произошли какие-то изменения в mysql и для работы с
новым сервером обязательно нужен новый клиент. Так что 3.x и 4.0 уже не
подходят.

PS: Могу и ошибаться... я уже плохо помню.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] python-module-MySQLdb требует пересборки?

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

On Sun, Aug 27, 2006 at 02:30:40AM +0900, Ivan Fedorov wrote:
> Насколько я помню свои разборки с каким-то криво настроенным хостингом,
> во времена 4.1.x произошли какие-то изменения в mysql и для работы с
> новым сервером обязательно нужен новый клиент. Так что 3.x и 4.0 уже не
> подходят.
> 
> PS: Могу и ошибаться... я уже плохо помню.

Разница между 5.0.22 и 5.0.24 дает SEGV.

$ perl -MDBD::mysql -le 'print DBD::mysql::dr::_ListDBs($sv)'                    
zsh: segmentation fault  perl -MDBD::mysql -le 'print DBD::mysql::dr::_ListDBs($sv)'
$ rpmpeek ~sisyphus/files/i586/RPMS/libMySQL-5.0.22-alt1.i586.rpm cp -pv ./usr/lib/libmysqlclient.so.15 $PWD                                                                                                            
`./usr/lib/libmysqlclient.so.15' -> `/home/at/RPM/BUILD/DBD-mysql-3.0006/libmysqlclient.so.15'
$ LD_LIBRARY_PATH=$PWD perl -MDBD::mysql -le 'print DBD::mysql::dr::_ListDBs($sv)'
information_schemamysqltest
$

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] python-module-MySQLdb требует пересборки?

[Vitaly Lipatov]

On Saturday 26 August 2006 17:57, Alexey Tourbin wrote:
> On Sat, Aug 26, 2006 at 03:22:49PM +0600, Eugene Vlasov wrote:
> > Добрый день.
> >
> > После обновления MySQL до 5.0.24-alt1 у меня отказалось
> > работать одно приложение, использующее python-module-MySQLdb
> > (1.2.0-alt0.1). Пересборка последнего вроде решила проблему.
> > Это у кого-то воспроизводится? Возможно и другие приложения
> > собранные с MySQL сломались?
>
> Так точно.  Проверил perl-DBD-mysql.  Пересборка и make test
> проходят нормально.  Но если в make test подсунуть ранее
Кстати, и OpenOffice.org тоже падает при обращении к MySQL

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

[devel] debug MySQL SEGV

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 9041 bytes --]

On Sat, Aug 26, 2006 at 06:43:06PM +0400, Alexey Tourbin wrote:
> On Sat, Aug 26, 2006 at 06:17:31PM +0400, Alexey Tourbin wrote:
> > > интересно, а что скажет abi-drift?
> > Он вроде заглох послденее время.  message size >1M.
> 
> Впрочем, abi_drift проверят только разрешимость символов.  То есть с
> abi_drift можно спрашивать, когда приложение падает по undefined symbol.
> Здесь что-то более тонкое.  Я попробовал в gdb расковырять но там
> сплошные callback'и, в общем боюсь что мне слабо такое расковырять.
> Но попробую ещё...

gdb не помогает. :(  Поэтому я выбрал другую тактику, и у меня появилось
обоснованное подозрение.  Изложу подробно, как я реализую эту тактику;
это может быть назидательным для других maintainer'ов.

Тактика состоит в том, чтобы проверить, *что именно* мы компилируем.
Сначала стивится libMySQL-devel 5.0.22 и делается gcc -E всех
компилируемых файлов (препроцессор).  Потом ставится libMySQL-devel
5.0.24 и опять делается gcc -E всех комплируемых файлов.  Потом на
раскрытые таким образом исходники сравниваются.

$ cd ~build/DBD-mysql-3.0006
$ rm -fv *.o
removed `dbdimp.o'
removed `mysql.o'
$ sudo rpm -Uv ~sisyphus/files/i586/RPMS/libMySQL*-5.0.22-alt1.i586.rpm --force --nodeps
Preparing packages for installation...             
libMySQL-5.0.22-alt1
libMySQL-devel-5.0.22-alt1
$

Поставил старые пакеты libMySQL.  Теперь нужно зопатчить Makefile,
чтобы вместо gcc -c выполнялся gcc -E.

$ diff Makefile{-,}
--- Makefile-   2006-08-26 14:21:28 +0000
+++ Makefile    2006-08-26 18:26:45 +0000
@@ -309,7 +309,7 @@ BSLOADLIBS = 
 
 
 # --- MakeMaker const_cccmd section:
-CCCMD = $(CC) -c $(PASTHRU_INC) $(INC) \
+CCCMD = $(CC) -E $(PASTHRU_INC) $(INC) \
        $(CCFLAGS) $(OPTIMIZE) \
        $(PERLTYPE) $(MPOLLUTE) $(DEFINE_VERSION) \
        $(XS_DEFINE_VERSION)
$

Теперь при попытке комплияции .c.o в stdout будут сыпаться раскрытые
исходники.

$ make dbdimp.o |tail -5
SV *mysql_db_last_insert_id(SV *dbh, imp_dbh_t *imp_dbh,
        SV *catalog, SV *schema, SV *table, SV *field, SV *attr)
{
  return Perl_sv_2mortal(((PerlInterpreter *)pthread_getspecific((*Perl_Gthr_key_ptr(((void *)0))))), my_ulonglong2str(mysql_insert_id(&((imp_dbh_t*)imp_dbh)->mysql)));
}
$

Значит, вывод можно сохранять.

$ make dbdimp.o >dbdimp.E1
$ make mysql.o >mysql.E1
$ ls -l *.E1
-rw-r--r-- 1 at at 596132 Aug 26 22:30 dbdimp.E1
-rw-r--r-- 1 at at 608773 Aug 26 22:30 mysql.E1
$

Теперь осталось поставить новую библиотеку и опять сохранить вывод.

$ sudo rpm -Uv ~sisyphus/files/i586/RPMS/libMySQL*-5.0.24-alt1.i586.rpm                 
Preparing packages for installation...                                                                          
libMySQL-5.0.24-alt1
libMySQL-devel-5.0.24-alt1
$ make dbdimp.o >dbdimp.E2
$ make mysql.o >mysql.E2

А теперь -- то, ради чего всё делалось: сравниваем полностью раскрытые
исходники.

$ diff -upbB dbdimp.E[12]
--- dbdimp.E1   2006-08-26 18:30:07 +0000
+++ dbdimp.E2   2006-08-26 18:40:43 +0000
@@ -15290,7 +15290,8 @@ enum mysql_option
   MYSQL_OPT_WRITE_TIMEOUT, MYSQL_OPT_USE_RESULT,
   MYSQL_OPT_USE_REMOTE_CONNECTION, MYSQL_OPT_USE_EMBEDDED_CONNECTION,
   MYSQL_OPT_GUESS_CONNECTION, MYSQL_SET_CLIENT_IP, MYSQL_SECURE_AUTH,
-  MYSQL_REPORT_DATA_TRUNCATION, MYSQL_OPT_RECONNECT
+  MYSQL_REPORT_DATA_TRUNCATION, MYSQL_OPT_RECONNECT,
+  MYSQL_OPT_SSL_VERIFY_SERVER_CERT
 };

 struct st_mysql_options {
@@ -15305,6 +15306,7 @@ struct st_mysql_options {
   char *ssl_ca;
   char *ssl_capath;
   char *ssl_cipher;
+  my_bool ssl_verify_server_cert;
   char *shared_memory_base_name;
   unsigned long max_allowed_packet;
   my_bool use_ssl;
@@ -15450,7 +15452,7 @@ typedef struct st_mysql_res {
   my_bool unbuffered_fetch_cancelled;
   const struct st_mysql_methods *methods;
 } MYSQL_RES;
-# 327 "/usr/include/mysql/mysql.h"
+# 329 "/usr/include/mysql/mysql.h"
 typedef struct st_mysql_manager
 {
   NET net;
@@ -15470,10 +15472,10 @@ typedef struct st_mysql_parameters
   unsigned long *p_max_allowed_packet;
   unsigned long *p_net_buffer_length;
 } MYSQL_PARAMETERS;
-# 357 "/usr/include/mysql/mysql.h"
+# 359 "/usr/include/mysql/mysql.h"
 int mysql_server_init(int argc, char **argv, char **groups);
 void mysql_server_end(void);
-# 371 "/usr/include/mysql/mysql.h"
+# 373 "/usr/include/mysql/mysql.h"
 MYSQL_PARAMETERS * mysql_get_parameters(void);


@@ -15515,6 +15517,7 @@ MYSQL * mysql_init(MYSQL *mysql);
 my_bool mysql_ssl_set(MYSQL *mysql, const char *key,
           const char *cert, const char *ca,
           const char *capath, const char *cipher);
+const char * mysql_get_ssl_cipher(MYSQL *mysql);
 my_bool mysql_change_user(MYSQL *mysql, const char *user,
        const char *passwd, const char *db);
 MYSQL * mysql_real_connect(MYSQL *mysql, const char *host,
@@ -15664,13 +15667,13 @@ int mysql_manager_fetch_line(MYSQL_MANAG
         char* res_buf,
        int res_buf_size);
 my_bool mysql_read_query_result(MYSQL *mysql);
-# 569 "/usr/include/mysql/mysql.h"
+# 572 "/usr/include/mysql/mysql.h"
 enum enum_mysql_stmt_state
 {
   MYSQL_STMT_INIT_DONE= 1, MYSQL_STMT_PREPARE_DONE, MYSQL_STMT_EXECUTE_DONE,
   MYSQL_STMT_FETCH_DONE
 };
-# 639 "/usr/include/mysql/mysql.h"
+# 642 "/usr/include/mysql/mysql.h"
 typedef struct st_mysql_bind
 {
   unsigned long *length;
@@ -15844,7 +15847,7 @@ my_bool mysql_autocommit(MYSQL * mysql,
 my_bool mysql_more_results(MYSQL *mysql);
 int mysql_next_result(MYSQL *mysql);
 void mysql_close(MYSQL *sock);
-# 837 "/usr/include/mysql/mysql.h"
+# 840 "/usr/include/mysql/mysql.h"
 unsigned long net_safe_read(MYSQL* mysql);
 # 22 "dbdimp.h" 2
 # 1 "/usr/include/mysql/mysqld_error.h" 1
/var/mail/at has mail!
$

И второй файл:

$ diff -upbB mysql.E[12]
--- mysql.E1    2006-08-26 18:30:19 +0000
+++ mysql.E2    2006-08-26 18:40:47 +0000
@@ -15291,7 +15291,8 @@ enum mysql_option
   MYSQL_OPT_WRITE_TIMEOUT, MYSQL_OPT_USE_RESULT,
   MYSQL_OPT_USE_REMOTE_CONNECTION, MYSQL_OPT_USE_EMBEDDED_CONNECTION,
   MYSQL_OPT_GUESS_CONNECTION, MYSQL_SET_CLIENT_IP, MYSQL_SECURE_AUTH,
-  MYSQL_REPORT_DATA_TRUNCATION, MYSQL_OPT_RECONNECT
+  MYSQL_REPORT_DATA_TRUNCATION, MYSQL_OPT_RECONNECT,
+  MYSQL_OPT_SSL_VERIFY_SERVER_CERT
 };

 struct st_mysql_options {
@@ -15306,6 +15307,7 @@ struct st_mysql_options {
   char *ssl_ca;
   char *ssl_capath;
   char *ssl_cipher;
+  my_bool ssl_verify_server_cert;
   char *shared_memory_base_name;
   unsigned long max_allowed_packet;
   my_bool use_ssl;
@@ -15451,7 +15453,7 @@ typedef struct st_mysql_res {
   my_bool unbuffered_fetch_cancelled;
   const struct st_mysql_methods *methods;
 } MYSQL_RES;
-# 327 "/usr/include/mysql/mysql.h"
+# 329 "/usr/include/mysql/mysql.h"
 typedef struct st_mysql_manager
 {
   NET net;
@@ -15471,10 +15473,10 @@ typedef struct st_mysql_parameters
   unsigned long *p_max_allowed_packet;
   unsigned long *p_net_buffer_length;
 } MYSQL_PARAMETERS;
-# 357 "/usr/include/mysql/mysql.h"
+# 359 "/usr/include/mysql/mysql.h"
 int mysql_server_init(int argc, char **argv, char **groups);
 void mysql_server_end(void);
-# 371 "/usr/include/mysql/mysql.h"
+# 373 "/usr/include/mysql/mysql.h"
 MYSQL_PARAMETERS * mysql_get_parameters(void);


@@ -15516,6 +15518,7 @@ MYSQL * mysql_init(MYSQL *mysql);
 my_bool mysql_ssl_set(MYSQL *mysql, const char *key,
           const char *cert, const char *ca,
           const char *capath, const char *cipher);
+const char * mysql_get_ssl_cipher(MYSQL *mysql);
 my_bool mysql_change_user(MYSQL *mysql, const char *user,
        const char *passwd, const char *db);
 MYSQL * mysql_real_connect(MYSQL *mysql, const char *host,
@@ -15665,13 +15668,13 @@ int mysql_manager_fetch_line(MYSQL_MANAG
         char* res_buf,
        int res_buf_size);
 my_bool mysql_read_query_result(MYSQL *mysql);
-# 569 "/usr/include/mysql/mysql.h"
+# 572 "/usr/include/mysql/mysql.h"
 enum enum_mysql_stmt_state
 {
   MYSQL_STMT_INIT_DONE= 1, MYSQL_STMT_PREPARE_DONE, MYSQL_STMT_EXECUTE_DONE,
   MYSQL_STMT_FETCH_DONE
 };
-# 639 "/usr/include/mysql/mysql.h"
+# 642 "/usr/include/mysql/mysql.h"
 typedef struct st_mysql_bind
 {
   unsigned long *length;
@@ -15845,7 +15848,7 @@ my_bool mysql_autocommit(MYSQL * mysql,
 my_bool mysql_more_results(MYSQL *mysql);
 int mysql_next_result(MYSQL *mysql);
 void mysql_close(MYSQL *sock);
-# 837 "/usr/include/mysql/mysql.h"
+# 840 "/usr/include/mysql/mysql.h"
 unsigned long net_safe_read(MYSQL* mysql);
 # 22 "dbdimp.h" 2
 # 1 "/usr/include/mysql/mysqld_error.h" 1
$

Глядя на diff, *единственное*, что приходит в голову -- это изменение
в структуре st_mysql_options.  Прямо посреди структуры добавилось новое
поле.  Если эта структура каким-либо косвенным образом экспозируется
в качестве API, тогда это объясняет сбои в работе.  Это и есть то
обоснованное подозрение, о котором я написал в начале.

Теперь классический вопрос: что делать?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] python-module-MySQLdb требует пересборки?

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

Hi Alexey!

Saturday 26, at 06:43:06 PM you wrote:

> On Sat, Aug 26, 2006 at 06:17:31PM +0400, Alexey Tourbin wrote:
> > > интересно, а что скажет abi-drift?
> > Он вроде заглох послденее время.  message size >1M.
> 
> Впрочем, abi_drift проверят только разрешимость символов.  То есть с
> abi_drift можно спрашивать, когда приложение падает по undefined symbol.
> Здесь что-то более тонкое.  Я попробовал в gdb расковырять но там
> сплошные callback'и, в общем боюсь что мне слабо такое расковырять.
> Но попробую ещё...
ага, тогда я им пожалуюсь, они уже так делали - меняли структуры без смены
soname, за что debian бил их по рукам.

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] debug MySQL SEGV

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

On Sat, Aug 26, 2006 at 10:48:48PM +0400, Alexey Tourbin wrote:
[...]
> Глядя на diff, *единственное*, что приходит в голову -- это изменение
> в структуре st_mysql_options.  Прямо посреди структуры добавилось новое
> поле.  Если эта структура каким-либо косвенным образом экспозируется
> в качестве API, тогда это объясняет сбои в работе.  Это и есть то
> обоснованное подозрение, о котором я написал в начале.

http://bugs.mysql.com/bug.php?id=21543

Действительно, в 5.0.24 ухитрились сломать ABI у libmysqlclient.
Этому способствовали ошибки дизайна API - внутренняя структура объекта
MYSQL (и многих других объектов) видима для пользователей библиотеки.

> Теперь классический вопрос: что делать?

Видимо, срочно патчить MySQL для восстановления совместимости по ABI
(патч уже доступен), после чего пересобирать всё, что успело собраться
с этой сборкой 5.0.24.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] python-module-MySQLdb требует пересборки?

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

On Sat, Aug 26, 2006 at 11:15:32PM +0400, Konstantin A. Lepikhov wrote:
> Hi Alexey!
> 
> Saturday 26, at 06:43:06 PM you wrote:
> 
> > On Sat, Aug 26, 2006 at 06:17:31PM +0400, Alexey Tourbin wrote:
> > > > интересно, а что скажет abi-drift?
> > > Он вроде заглох послденее время.  message size >1M.
> > 
> > Впрочем, abi_drift проверят только разрешимость символов.  То есть с
> > abi_drift можно спрашивать, когда приложение падает по undefined symbol.
> > Здесь что-то более тонкое.  Я попробовал в gdb расковырять но там
> > сплошные callback'и, в общем боюсь что мне слабо такое расковырять.
> > Но попробую ещё...
> ага, тогда я им пожалуюсь, они уже так делали - меняли структуры без смены
> soname, за что debian бил их по рукам.

http://bugs.mysql.com/bug.php?id=21543
via vsu

vsu также говорит, что исправление уже включено в 5.0.24a.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] debug MySQL SEGV

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

Hi Sergey!

Saturday 26, at 11:22:11 PM you wrote:

> On Sat, Aug 26, 2006 at 10:48:48PM +0400, Alexey Tourbin wrote:
> [...]
> > Глядя на diff, *единственное*, что приходит в голову -- это изменение
> > в структуре st_mysql_options.  Прямо посреди структуры добавилось новое
> > поле.  Если эта структура каким-либо косвенным образом экспозируется
> > в качестве API, тогда это объясняет сбои в работе.  Это и есть то
> > обоснованное подозрение, о котором я написал в начале.
> 
> http://bugs.mysql.com/bug.php?id=21543
> 
> Действительно, в 5.0.24 ухитрились сломать ABI у libmysqlclient.
> Этому способствовали ошибки дизайна API - внутренняя структура объекта
> MYSQL (и многих других объектов) видима для пользователей библиотеки.
> 
> > Теперь классический вопрос: что делать?
> 
> Видимо, срочно патчить MySQL для восстановления совместимости по ABI
> (патч уже доступен), после чего пересобирать всё, что успело собраться
> с этой сборкой 5.0.24.
да, я сейчас залью в i/S версию с этим патчем.

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] debug MySQL SEGV

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

Hi Sergey!

Saturday 26, at 11:22:11 PM you wrote:

<skip>
> > Теперь классический вопрос: что делать?
> 
> Видимо, срочно патчить MySQL для восстановления совместимости по ABI
> (патч уже доступен), после чего пересобирать всё, что успело собраться
> с этой сборкой 5.0.24.
из последних надо пересобрать php-mysql/php5-mysql и, возможно, dovecot. 

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] debug MySQL SEGV

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

On Sun, Aug 27, 2006 at 12:22:35AM +0400, Konstantin A. Lepikhov wrote:
> > Видимо, срочно патчить MySQL для восстановления совместимости по ABI
> > (патч уже доступен), после чего пересобирать всё, что успело собраться
> > с этой сборкой 5.0.24.
> из последних надо пересобрать php-mysql/php5-mysql и, возможно, dovecot. 

Вот полный список.

at@mash files/i586/RPMS $ mybuildtime=`rpm -qp --qf '%{BUILDTIME}\n' libMySQL-5.0.24-alt1.i586.rpm`
at@mash files/i586/RPMS $ ls -1 |xargs rpm -qp --qf "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm\t%{BUILDTIME}\n" |
	awk -F'\t' "\$2>$mybuildtime-24*3600" |cut -f1 |
		xargs rpm -qp --qf '[%{REQUIRENAME}\t%{SOURCERPM}\n]' |
			awk -F'\t' '$1~/libmysqlclient/{print$2}' |sort -u
MySQL-5.0.24-alt1.src.rpm
asterisk1.3-addons-1.3.0-alt1.20060818.src.rpm
asterisk1.3-addons-1.3.0-alt1.20060820.src.rpm
dovecot-1.0-alt4.cvs20060812.src.rpm
freeradius-1.1.2-alt3.src.rpm
hk_classes-0.8.1a-alt3.src.rpm
php-mysql-4.4.4-alt1.src.rpm
php5-mysql-5.1.5-alt1.src.rpm
at@mash files/i586/RPMS $ 

Есть некоторые сомнения насчет $mybuildtime-24*3600.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] debug MySQL SEGV

[Денис Смирнов]

On Sun, Aug 27, 2006 at 12:34:48AM +0400, Алексей Турбин wrote:

AT> asterisk1.3-addons-1.3.0-alt1.20060818.src.rpm
AT> asterisk1.3-addons-1.3.0-alt1.20060820.src.rpm

А вот кто-нибудь может мне объяснить, каким образом их двое оказалось?
Рассинхронизации между x86_64 и i686 быть не могло просто потому, что оно
до сих пор на x86_64 не собирается.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
[...] python22-devel тоже provides python-devel, и он лексикографически
круче.
		-- ldv in devel@

Re: [devel] debug MySQL SEGV

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]

On Sun, Aug 27, 2006 at 11:03:19AM +0400, Денис Смирнов wrote:
> On Sun, Aug 27, 2006 at 12:34:48AM +0400, Алексей Турбин wrote:
> 
> AT> asterisk1.3-addons-1.3.0-alt1.20060818.src.rpm
> AT> asterisk1.3-addons-1.3.0-alt1.20060820.src.rpm
> 
> А вот кто-нибудь может мне объяснить, каким образом их двое оказалось?
> Рассинхронизации между x86_64 и i686 быть не могло просто потому, что оно
> до сих пор на x86_64 не собирается.

Похоже что они разом прошли.

at@mash files/i586/RPMS $ l *asterisk*.200608{18,20}* 
-rw-r--r-- 1 copy copy  24353 Aug 21 21:48 asterisk1.3-format_mp3-1.3.0-alt1.20060818.i586.rpm
-rw-r--r-- 1 copy copy  24500 Aug 21 21:48 asterisk1.3-format_mp3-1.3.0-alt1.20060820.i586.rpm
-rw-r--r-- 1 copy copy  28805 Aug 21 21:48 asterisk1.3-mysql-1.3.0-alt1.20060818.i586.rpm
-rw-r--r-- 1 copy copy  28954 Aug 21 21:48 asterisk1.3-mysql-1.3.0-alt1.20060820.i586.rpm
-rw-r--r-- 1 copy copy  32604 Aug 21 21:48 asterisk1.3-app_conference-1.3.0-alt1.20060818.i586.rpm
-rw-r--r-- 1 copy copy  32752 Aug 21 21:48 asterisk1.3-app_conference-1.3.0-alt1.20060820.i586.rpm
-rw-r--r-- 1 copy copy 392009 Aug 21 21:48 asterisk1.3-chan_ooh323-1.3.0-alt1.20060818.i586.rpm
-rw-r--r-- 1 copy copy 392156 Aug 21 21:48 asterisk1.3-chan_ooh323-1.3.0-alt1.20060820.i586.rpm
at@mash files/i586/RPMS $ pwd
/arch1/ALT/Sisyphus/files/i586/RPMS
at@mash files/i586/RPMS $ 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] debug MySQL SEGV

[Денис Смирнов]

On Sun, Aug 27, 2006 at 04:37:49PM +0400, Алексей Турбин wrote:

>> А вот кто-нибудь может мне объяснить, каким образом их двое оказалось?
>> Рассинхронизации между x86_64 и i686 быть не могло просто потому, что оно
>> до сих пор на x86_64 не собирается.
AT> Похоже что они разом прошли.

В смысле одновременно две версии до пересборки? Да, так и есть.
Правда отправлял я их с перерывом. Странно.
Кстати ещё странно было когда изменился пакет, из которого формировался
бинарный пакет muted, в репозитории оказался старый muted, а не новый. То
бишь для бинарных пакетов соответствие их исходным не проверяется.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
"я тебя открыл, я тебя и closed"
		-- mike in #4235

Re: [devel] debug MySQL SEGV

[Michael Shigorin]

On Sat, Aug 26, 2006 at 11:22:11PM +0400, Sergey Vlasov wrote:
> > Теперь классический вопрос: что делать?
> Видимо, срочно патчить MySQL для восстановления совместимости
> по ABI (патч уже доступен), после чего пересобирать всё, что
> успело собраться с этой сборкой 5.0.24.

Everything that has been compiled during the last days against
specificly 5.0.24 has to be rebuild with 5.0.24a.
	-- http://lists.mysql.com/packagers/318

2 at: Лёш, возможно, это халтура -- они и в 4.x за последние
полгода похожую мину подсунули.  В смысле там есть знакомый
народ, мож имеет смысл их познакомить с твоими роботами по 
$$$$/кг?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] debug MySQL SEGV

[Alexey Rusakov]

Michael Shigorin пишет:
> Everything that has been compiled during the last days against
> specificly 5.0.24 has to be rebuild with 5.0.24a.
> 	-- http://lists.mysql.com/packagers/318
>
> 2 at: Лёш, возможно, это халтура -- они и в 4.x за последние
> полгода похожую мину подсунули.  В смысле там есть знакомый
> народ, мож имеет смысл их познакомить с твоими роботами по 
> $$$$/кг?
>   
У меня там тоже есть знакомый народ :) роботы не помогут, это не 
халтура, а вопрос политики. Они понимают, что это плохо, но иногда 
предпочитают решать проблему развития вот так.

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] debug MySQL SEGV

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 788 bytes --]

On Sun, Aug 27, 2006 at 12:34:48AM +0400, Alexey Tourbin wrote:
> On Sun, Aug 27, 2006 at 12:22:35AM +0400, Konstantin A. Lepikhov wrote:
> > > Видимо, срочно патчить MySQL для восстановления совместимости по ABI
> > > (патч уже доступен), после чего пересобирать всё, что успело собраться
> > > с этой сборкой 5.0.24.

Я протестировал MySQL-5.0.24-alt2, с ним перловый драйвер работает
нормально.

> > из последних надо пересобрать php-mysql/php5-mysql и, возможно, dovecot. 
> Вот полный список.

Прошу incoming пересобрать роботом следующие пакеты:

> dovecot-1.0-alt4.cvs20060812.src.rpm
> freeradius-1.1.2-alt3.src.rpm
> hk_classes-0.8.1a-alt3.src.rpm
> php-mysql-4.4.4-alt1.src.rpm
> php5-mysql-5.1.5-alt1.src.rpm

Changelog:
- Rebuilt with MySQL-5.0.24-alt2.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] debug MySQL SEGV

[Michael Shigorin]

On Wed, Aug 30, 2006 at 09:49:33AM +0400, Alexey Rusakov wrote:
> > Everything that has been compiled during the last days against
> > specificly 5.0.24 has to be rebuild with 5.0.24a.
> > 	-- http://lists.mysql.com/packagers/318
> > 2 at: Лёш, возможно, это халтура -- они и в 4.x за последние
> > полгода похожую мину подсунули.  В смысле там есть знакомый
> > народ, мож имеет смысл их познакомить с твоими роботами по 
> > $$$$/кг?
> У меня там тоже есть знакомый народ :) роботы не помогут, это
> не халтура, а вопрос политики. Они понимают, что это плохо, но
> иногда предпочитают решать проблему развития вот так.

Судя по packagers@ и откатам, именно ляпы и ни разу не политика.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [jt] debug MySQL SEGV

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

On Sat, Sep 02, 2006 at 04:22:49PM +0300, Michael Shigorin wrote:
> On Wed, Aug 30, 2006 at 09:49:33AM +0400, Alexey Rusakov wrote:
> > > Everything that has been compiled during the last days against
> > > specificly 5.0.24 has to be rebuild with 5.0.24a.
> > > 	-- http://lists.mysql.com/packagers/318
> > > 2 at: Лёш, возможно, это халтура -- они и в 4.x за последние
> > > полгода похожую мину подсунули.  В смысле там есть знакомый
> > > народ, мож имеет смысл их познакомить с твоими роботами по 
> > > $$$$/кг?
> > У меня там тоже есть знакомый народ :) роботы не помогут, это
> > не халтура, а вопрос политики. Они понимают, что это плохо, но
> > иногда предпочитают решать проблему развития вот так.
> 
> Судя по packagers@ и откатам, именно ляпы и ни разу не политика.

Политика ляпов и откатов. :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] debug MySQL SEGV

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

On Wed, Aug 30, 2006 at 02:55:48AM +0300, Michael Shigorin wrote:
> On Sat, Aug 26, 2006 at 11:22:11PM +0400, Sergey Vlasov wrote:
> > > Теперь классический вопрос: что делать?
> > Видимо, срочно патчить MySQL для восстановления совместимости
> > по ABI (патч уже доступен), после чего пересобирать всё, что
> > успело собраться с этой сборкой 5.0.24.
> 
> Everything that has been compiled during the last days against
> specificly 5.0.24 has to be rebuild with 5.0.24a.
> 	-- http://lists.mysql.com/packagers/318
> 
> 2 at: Лёш, возможно, это халтура -- они и в 4.x за последние
> полгода похожую мину подсунули.  В смысле там есть знакомый
> народ, мож имеет смысл их познакомить с твоими роботами по 
> $$$$/кг?

Мои роботы несовместимость по структурам данных не обнаруживают.
Хороший API просто не экспозирует сами структуры, а только указатели 
через неполное определение.  Никакого энтузиазма по поводу MySQL я не 
испытываю; $$$$/кг это конечно заманчиво, но, в общем, боюсь, что с 
такими предложениями лучше к Перельману.

Может, они заинтересованы в тестировании чего-нибудь более приличного,
типа PostgreSQL? :-)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]