Russian Apache Switch to English
Switch to Russian koi8-r
windows=1251
cp-866
iso8859-5
Russian Apache Как это работает Рекоммендации Где взять Как установить Как настроить Статус и поддержка
Краткий обзор FAQ Список рассылки Благодарности Поиск по серверу Powered by Russian Apache
Russian Apache mailing list archive (apache-rus@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[apache-talk] mod_python - problem with dynamic loading



Здравствуйте, господа.

   Нужен совет человека, понимающего в устройстве ELF и разделяемых
библиотеках.

   Имеется Python 1.5.1, Apache 1.3.4 и PyApache - это такой mod_python.
Сам этот PyApache представляет собой крайне простой модуль, который
линкуется статически с питоном (libpython.a). А вот уже интерпретатор
питона тянет за собой кучу модулей, скомпилированных в виде разделяемых
библиотек; подгружаются они по мере обращения к ним.

   Сначала все это было поставлено на Сан, Солярис 2.5.1. Все прекрасно
работало. Попытка перенести все это на линукс, однако, провалилась. Не
работает, при чем не работает по-разному в зависимости от фазы луны.

   Проблемы начались с того, что PyApache, скомпилированный для линукса,
отказывался подгружать пионовские .so-модули. То есть скрипт начинал
работать, даже какие-то простые действия можно делать, но стоило попытаться
проимпортировать скомпилированный модуль - pyapache падал, и в error_log
появлялась надпись (от обработчика ошибок самого pyapache) - не могу найти
символ _Py_чтототам (символ, по логике вещей, должен находиться в
libpython.a, к тому времени жить в памяти вместе с pyapache).

   Поиск по mail-листу pyapache показал, что не у одного меня проблемы:
http://www.egroups.com/group/pyapache-devel/132.html
   У человека такая же конфигурация, как у меня - в смысле, так же как и у
меня, стоит постгрес. Оч хор, я стал экспериментировать. Для начала убрал
из апача mod_auth_pgsql. PyApache заработал на одной из машин, я попытался
перекомпилировать на другую машину (на одной Debian 2.1, на второй RH 5.1.)
Не завелось, при чем не завелось по-другому - в error_log появились
segmentation fault.
   Я вернул на первой машине mod_auth_pgsql - pyapache некоторое время
поработал, потом тоже стал давать segmentation fault.

   В это время мне подвалила еще одна машина с RH 5.2. Администрил ее не я,
человек под моим руководством поставил питон и pyapache - все работало...
но в error_log - segmentation fault. То есть, я так понимаю, он там
появляется после отработки скрипта.
   Апач на той машине несколько раз перекомпиляли для разных нужд -
поставили mod_perl, потом mod_auth_mysql - pyapache работал, а этот
segmentation fault иногда исчезает на некоторое время, иногда возвращается.

   В процессе экспериментов я поставил на сане и двух своих линуксах python
1.5.2 и apache 1.3.6 - ничего не изменилось. На сане работает как часы, на
линуксе ругается на символ _Py_XXX (другой).

   Кто-нибудь понимает, что происходит? Хоть какой-нибудь совет, где
покопаться...

Oleg.
---- 
    Oleg Broytmann  National Research Surgery Centre  http://sun.med.ru/~phd/
           Programmers don't die, they just GOSUB without RETURN.

=============================================================================
=               Apache-Talk@xxxxxxxxxxxxx mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@xxxxxxxxxxxxx if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =






Спонсоры сайта:

[ Russian Apache ] [ Как это работает ] [ Рекомендации ] [ Где взять ] [ Как установить ] [ Как настроить ] [ Статус и поддержка ] [ Краткий обзор ] [ FAQ ] [ Список рассылки ] [ Благодарности ] [ Поиск по серверу ] [ Powered by Russian Apache ] [ Apache-talk archive ]

"Russian Apache" includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/) See Apache LICENSE.
Copyright (C) 1995-2001 The Apache Group. All rights reserved.
Copyright (C) 1996 Dm. Kryukov; Copyright (C) 1997-2009 Alex Tutubalin. Design (C) 1998 Max Smolev.