Собственно сабж.
Апач вот такой Apache/1.3.34
компилятор апачевского модуля gcc42
Модулл для апача падает всё время в разных местах libstdc++,
в основном во всяких стд-шных конструкциях, примеры ниже.
в коде никакого динамического выделения памяти не происходит
сплошные std контейнеры.
Никакой замены стандартных sdt алокаторов тоже не делал.
Были подозрения на то, что использовали разные версии либок libstdc++ и libc
в этом апачевском модуле используються вот такие либы
libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x282ac000)
libgd.so.4 => /usr/local/lib/libgd.so.4 (0x282cd000)
libctpp.so.1 => /usr/local/lib/libctpp.so.1 (0x2831f000)
libstdc++.so.6 => /usr/local/lib/gcc-4.2.3/libstdc++.so.6 (0x28363000)
libm.so.3 => /lib/libm.so.3 (0x2843c000)
libgcc_s.so.1 => /usr/local/lib/gcc-4.2.3/libgcc_s.so.1 (0x28457000)
libpng.so.5 => /usr/local/lib/libpng.so.5 (0x28461000)
libz.so.2 => /lib/libz.so.2 (0x28484000)
libjpeg.so.9 => /usr/local/lib/libjpeg.so.9 (0x28494000)
libfreetype.so.9 => /usr/local/lib/libfreetype.so.9 (0x284b1000)
libc.so.5 => /lib/libc.so.5 (0x28079000)
Уже весь мозг сломал не пойму в чем дело.
Пример 1.(стек из гдб)
#0 0x2813c2f2 in ldexp () from /lib/libc.so.5
#1 0x2813c743 in ldexp () from /lib/libc.so.5
#2 0x2813c874 in free () from /lib/libc.so.5
#3 0x284a036b in operator delete () from /usr/local/lib/gcc-4.2.3/libstdc++.so.6
#4 0x2848220f in std::string::_Rep::_M_destroy () from /usr/local/lib/gcc-4.2.3/libstdc++.so.6
#5 0x28483af2 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string ()
from /usr/local/lib/gcc-4.2.3/libstdc++.so.6
#6 0x28297ff1 in direct_handler_ns::direct_handler::process_response () from /usr/local/libexec/apache/apache_module.so
#7 0x2830ffeb in CKqueueSheduler::ProcessRecvMessages () from /usr/local/libexec/apache/apache_module.so
#8 0x28310350 in CKqueueSheduler::WaitQuote () from /usr/local/libexec/apache/apache_module.so
#9 0x2831121c in CKqueueSheduler::Process () from /usr/local/libexec/apache/apache_module.so
#10 0x2824a20c in sc_core_ns::processor_core::handler () from /usr/local/libexec/apache/apache_module.so
#11 0x28225d51 in process_request () from /usr/local/libexec/apache/apache_module.so
Пример 2.
#0 0x2813037b in kill () from /lib/libc.so.5
#1 0x28125422 in raise () from /lib/libc.so.5
#2 0x28197c1b in abort () from /lib/libc.so.5
#3 0x2813b5b9 in ldexp () from /lib/libc.so.5
#4 0x2813c3de in ldexp () from /lib/libc.so.5
#5 0x2813c743 in ldexp () from /lib/libc.so.5
#6 0x2813c874 in free () from /lib/libc.so.5
#7 0x284a036b in operator delete () from /usr/local/lib/gcc-4.2.3/libstdc++.so.6
#8 0x2848220f in std::string::_Rep::_M_destroy () from /usr/local/lib/gcc-4.2.3/libstdc++.so.6
#9 0x28483af2 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string ()
from /usr/local/lib/gcc-4.2.3/libstdc++.so.6
#10 0x282cc6f5 in yandex_handler_ns::yandex_handler::process_response () from /usr/local/libexec/apache/apache_module.so
#11 0x2830ffeb in CKqueueSheduler::ProcessRecvMessages () from /usr/local/libexec/apache/apache_module.so
#12 0x28310350 in CKqueueSheduler::WaitQuote () from /usr/local/libexec/apache/apache_module.so
#13 0x2831121c in CKqueueSheduler::Process () from /usr/local/libexec/apache/apache_module.so
#14 0x2824a20c in sc_core_ns::processor_core::handler () from /usr/local/libexec/apache/apache_module.so
#15 0x28225d51 in process_request () from /usr/local/libexec/apache/apache_module.so
#16 0x2826377e in apache_module_handler () from /usr/local/libexec/apache/apache_module.so
Здравствуйте, Vadya, Вы писали:
V>Собственно сабж.
V>Апач вот такой Apache/1.3.34
V>компилятор апачевского модуля gcc42
V>Модулл для апача падает всё время в разных местах libstdc++,
V>в основном во всяких стд-шных конструкциях, примеры ниже.
V>в коде никакого динамического выделения памяти не происходит
V>сплошные std контейнеры.
V>Никакой замены стандартных sdt алокаторов тоже не делал.
V>Были подозрения на то, что использовали разные версии либок libstdc++ и libc
V>в этом апачевском модуле используються вот такие либы
не скорее всетаки не это... -- у тя не грузился бы модуль нормально ругаясь на всякие символы типа GLIBC_2.N или там GCC_4.X.Y...
V>Уже весь мозг сломал не пойму в чем дело.
приведенные быктрэйсы выглядят как типичное удаление невалидной строки...
что были за строки то? чонить прочитанное из конфигов модуля?
не забываем также о том что апач на лету форкает процессы и\или threadы и также внезапно их мочит... -- отсуда большенство проблем с деструкторами при написании модулей на С++...
использовать stdшные контейнеры с дефолтным аллокатором нада оч осторожно... у апача свой memory management и свои понятия о времени жизни объектов (часто не совпадающие с С++ными)
если код не сильно наворочен (ну там без буста например
) буит немного проще если сделать свой аллокатор работающий с апачными пулами и инстанциировать им используемые контейнеры...
namespace apr {
/**
* \brief STL compatible allocator layed over APR pools
*/
template <typename T>
class pool_allocator
{
...
};
typedef std::basic_string<
char
, std::char_traits<char>
, pool_allocator<char>
> string;
}
но конечно же есть и сложности...
Здравствуйте, Vadya, Вы писали:
V>Забыл написать, падает он от вот этого
V>Program terminated with signal 11, Segmentation fault.
Обращение к невалидной памяти
Выдержка из мана
Signal Value Action Term
SIGSEGV 11 Core Invalid memory reference
