К сожалению, совершенно не являюсь ни знатоком по C++, ни по системному программированию. Поэтому мне требуется помощь настоящих специалистов.
У меня есть программа, которая написана на С++ (есть исходники) и откомпилирована под 32-битную Ubuntu 14.04. Обычно эта программа работает нормально, но на некоторых комбинациях входящих данных она тихо умирает с
Segmentation fault. Поскольку приложение работает в качестве многопоточного сервера, то ранее понять что и как его роняло у меня было не возможности. И я, как сисадмин, мог решать данную проблему только перезапуском демона. Но за вчера был всего один запрос, который успешно завалил этот сервер. Повторный его вызов все так же успешно убивает приложение.
Вооружившись знаниями из гугла, в скрипт из /etc/init.d я дописал перед стартом строчку
ulimit -c unlimited и получил при падении дамп. Далее скормил его на вход GDB и получил следующую информацию:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x080ac8a6 in size (this=<optimized out>, this=<optimized out>) at /usr/include/c++/4.8/bits/stl_vector.h:646
646 { return size_type(this->_M_impl._M_finish - this->_M_impl._M_start); }
Предпоследняя команда по бэктрейсу - это попытка вызова метода size() у вектора из экземпляров некоего класса. Что еще раз подтверждает порождение проблемы во внутренностях STL.
Моих скудных познаний по С++ в объеме двух семестров университета не достаточно, что бы понять причину выбивания
Segmentation fault выражением size_type. Совершенно не понятна причина, по которой на большинстве наборов данных все отрабатывает отлично, а ошибку выбивает лишь примерно раз в неделю - хотя данные в среднем однотипные и сбойный набор на глаз ничем не выделяется. Прошу помощи у знающих. Заранее спасибо!
P.S. Не знаю на сколько это важная информация, но лишней она точно не будет. Размер дампового файла 2335М. Работающее приложение в рабочее время показывает следующие показатели потребления памяти: VIRT=2295636, RES=2,11g. Т.е. насколько я понимаю до линуксовой границы в 3g для 32-битный приложений еще далековато. Утечки памяти если и есть, то незначительные (я за неделю-две стабильной работы не успеваю зафиксировать), а приложение успешно падает сразу после запуска без наличия дополнительной нагрузки пользовательскими запросами и с достаточным запасом оперативки для своих вычислений.
Upd. Программа сейчас работает в 3 потока и действительно существуют данные, к которым есть рабочие обращения из всех потоков. Но эти данные используются исключительно для чтения (после запуска программы 2 Гига поднимаются в память и более не изменяются). Сервер получает запрос и передает управление свободному потоку, который делает выборки из общих данных и выполняет требуемые от него расчеты. Еще раз при этом данные на самом сервере не изменяются! Потоки внутри себя создают требуемые для ихних алгоритмов структуры, а по завершению очищают от них память. Так же еще раз подчеркну, что ошибка может выбиваться на всего одном запросе в одном потоке при отсутствии активности от других потоков. В программе есть всего один критический управленческий участок, но доступ к нему регламентирован с помощью мютексов, и он не связан с выполняемыми расчетами и совершенно не имеет никакого отношения к алгоритму и данным в точке падения.
