madf

Так это не проблемы stargazer а проблемы файрвола.

Хочется 3-й версии? Спешу разочаровать, ее еще долго не будет. Изменения планируемые на 3-ю версию слишком значительны. Непонятно - это как? Раз в тупик ставит - значит с этим что-то надо делать... Keen говорил, что периодичность повторения бага у него составляла от 2 до 48 часов - по этом и ждем 2 суток. Неплохо было-бы, если бы Keen, Silitra и Dimension отписали.

Это не аллогизмы, это такая логика. Обработка начала месяца - запись и сброс трафика. К стати, перед вызовом в комментарии так и написано. Тут на самом деле полезного ничего не происходит, но на всякий случай, если вдруг потом навернем логику Connect/Disconnect Параметр true в этих двух вызовах говорит о том, что это не настоящие Connect и Disconnect. Физического отключения пользователя не происходит. Это, я думаю, из USER::MidnightResetSessionStat? Но там тоже в параметрах указано true. Собственно, те-же яйца, что и в USER::ProcessNewMonth.

Я жду еще пару суток, после чего выкладываю beta-версию.

Отлично

В файле stglibs/common.lib/common.cpp в строке 794 заменить uint16_t на uint32_t; в строке 801 заменить uint16_t на uint64_t. Авторизация раньше тупила потому, что на самом деле пользователь не авторизовался. Благодаря этим исследованиям еще один баг обнаружился

2.405 последний

Условия возникновения бага достаточно "узкие", по этому он не у всех проявляется и его так сложно было найти.

inetaccess.cpp > 20:07:17 > --->>> cash: 10000 inetaccess.cpp > 20:07:17 > --->>> cash: 4135 И что думает об этом авторизатор? Проходит авторизация или нет?

Смотри предыдущий пост

Теоретическое обоснование Когда пакет добавляется в трафкаунтер (TRAFFCOUNTER::Process) для него проверяется наличие авторизованных пользователей, для которых он может быть исходящим или входящим. Если таковые существуют - их итераторы записываются в поля userU и userD и помечаются соответствующие флаги userUPresent и userDPresent (для итератора не существует определенного NULL-состояния). После этого пакет попадает во внутреннее дерево пакетов трафкаунтера. При чем это происходит даже в том случае, если не существует авторизованных пользователей, которым бы этот пакет принадлежал. Когда пак

Так, есть идея. В файле traffcounter.cpp в методе DelUser заменить условия: (у меня это строка 612) if (pi.first->second->second.dirU < DIR_NUM) на if (pi.first->second->second.dirU < DIR_NUM && pi.first->second->second.userUPresent) и (у меня это строка 636) if (pi.first->second->second.dirD < DIR_NUM) на if (pi.first->second->second.dirD < DIR_NUM && pi.first->second->second.userDPresent)

Нашел интересную закономерность: когда ты первый раз сообщил о падении и предоставил лог - в STG_LOCKER передавался указатель на мьютекс с адресом 0x1F54 (явно вне адресуемого пространства процесса). Потом был еще лог со значением 0x1F60 (тоже рядом) и вчерашний лог - тоже с 0x1F60. Таким образом, в user.cpp:884 происходит вызов с уже невалидными параметрами. Далее интересные вещи творятся здесь (Keen): http://local.com.ua/forum/index.php?showto...amp;#entry99601 И здесь (Silitra): http://local.com.ua/forum/index.php?showto...mp;#entry100535 А именно (Keen): #6 0x080ab985 in USER::Unautho

Плохо-то как... Я уже начинаю подозревать сам мускул

Лог valgrind получил, спасибо. Там много интересного!

Трафик считает не "ключ". Трафик считается на сервере (или на сенсоре, если у вас NetFlow).

Попробуй опять-же, запустить из-под gdb. После падения сделать bt В первой строке будет что-то вроде: #0 0xf730db38 in MYSQL_STORE::GetMessage () from /usr/lib/stg/mod_store_mysql.so 0xf730db38 - адрес (будет по идее другой) Сделай list *0xf730db38 (только подставь тот адрес который у тебя будет вместо 0xf730db38)

А модуль mysql - тот который идет в архиве?

"База на спарке, сервер СТГ на интеле он подключается к БД на спарк " А, вот даже как... Блин, почему оно номера строк не показывает

А падает все время на одном и том-же юзере? Выхлоп valgrind был бы очень полезен...

Сборка была отладочной? Попробуй запустить старгейзер из-под gdb: $ gdb /path/to/stargazer (gdb) run и когда упадет сделать (gdb) bt И еще попробуй запустить старгейзер из-под valgrind: $ valgrind /path/to/stargazer Естественно интересует выхлоп в момент падения. PS: сообщение "Backtrace stopped: previous frame identical to this frame (corrupt stack?)", судя по гуглю, характерно для gdb на не-x86 архитектурах. Боюсь, что из этого ничего не получится

Сделать отладочный билд, получить корку (перед запуском выполнить ulimit -c 10000), после этого $ gdb ./stargazer (gdb) core-file <файл_корки> (gdb) bt И выхлоп мне

projects/stargazer/build:167 - заменить 0 на 1 в строке if [ $? == 0 ]

Еще один патч. Применять как и предыдущий. Запустишь, попробуешь авторизоваться, а потом кинешь мне консольный лог старгейзера. endianess.patch.txt

Хм, а при запуске точно используются либы и плагины текущей сборки? Не могло случиться такого, что stargazer продолжает использоват старые либы и плагины? Или новые либы и старые плагины?