2.406-alpha

[madf 279]

Не хочу сглазить, но последние версии стг (как альфа так и предыдущая) просто отлично работают с файловой базой! На MySQL переходить нет ни планов ни желания.

Имею в виду восстановление информации при аппаратных сбоях. Типа внезапного отключения питания.

[Keen 10]

Сегодня произвошло два падения.

Одно ровно в 02:00:20, в это же время моргнул свет и подвис инет. Может совпадение?

Второе с утречка. Последнии строчки консоли:

 

inetaccess.cpp > 09:28:14 > 1235287798.366477 384 bytes sent to 192.168.0.4:5555 len=384

inetaccess.cpp > 09:28:14 > Send_ALIVE_SYN_8

inetaccess.cpp > 09:28:14 > recv from 192.168.0.4 5555 len=64

inetaccess.cpp > 09:28:14 > User kirill FOUND!

inetaccess.cpp > 09:28:14 > ======================> InitEncrypt dont needed

inetaccess.cpp > 09:28:14 > Monitor time 1235269003 1235287754

inetaccess.cpp > 09:28:14 > recv from 194.169.205.31 5555 len=96

inetaccess.cpp > 09:28:14 > User virus FOUND!

inetaccess.cpp > 09:28:14 > ======================> InitEncrypt dont needed

inetaccess.cpp > 09:28:14 > 1235287798.422025 32 bytes sent to 194.169.205.31:5555 len=32

inetaccess.cpp > 09:28:14 > Monitor time 1235269003 1235287754

inetaccess.cpp > 09:28:14 > recv from 194.169.205.31 5555 len=64

inetaccess.cpp > 09:28:14 > User virus FOUND!

inetaccess.cpp > 09:28:14 > ======================> InitEncrypt dont needed

inetaccess.cpp > 09:28:14 > Send_FIN_8

users.cpp > 09:28:14 > Del IP Idx

traffcounter.cpp > 09:28:14 > DelUser: virus

Killed

 

Корки нет, есть лог valgrind на 20кб. Могу скинуть, если там есть что-то интересное......

[madf 279]

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

[madf 279]

Нашел интересную закономерность: когда ты первый раз сообщил о падении и предоставил лог - в 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::Unauthorize (this=0x83aade8, auth=0x80f0d80) at user.cpp:574 - тут вроде все хорошо, запоминаем this

#3 0x080a4873 in TRAFFCOUNTER::DelUser (this=0x80f01a0, user= {_M_node = 0x83aade0}) at traffcounter.cpp:616 - тут тоже хорошо (_M_node - внутренности итератора, допускаем смещение на 8 байт ДО юзера)

#2 0x080ac432 in USER::AddTraffStatU (this=0x8, dir=1, ip=3843359321, port=443, len=48) at user.cpp:884 - тут все плохо. this не может быть 8.

И тут похоже (Silitra):

#6 0x080a756f in USER::Unauthorize (this=0x28d22008, auth=0x2844e000) at user.cpp:583 - все так-же хорошо, обращаем внимание на this

#3 0x0809f282 in TRAFFCOUNTER::DelUser (this=0x2843b060, user={_M_node = 0x28d22000}) at traffcounter.cpp:605 - тоже неплохо (такое-же смещение на 8 байт)

#2 0x080a802a in USER::AddTraffStatU (this=0x8, dir=0, ip=3832810564, dport=59127, sport=47747, len=131) at user.cpp:911 - тут все поломалось

 

В TRAFFCOUNTER::DelUser вызовы AddTraffStatU не используют полученный итератор а производят поиск по внутреннему индексу. Похоже, портится индекс...

Пошел изучать дальше.

[madf 279]

Так, есть идея.

В файле 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)

[madf 279]

Теоретическое обоснование

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

Когда пакет становится "старше" FLUSH_TIME - трафкаунтер пытается отдать информацию о трафике пользователям из полей userU и userD, если таковые имеются в наличии. Если их нет - пакет живет до REMOVE_TIME и после этого стирается.

Когда пользователь авторизуется для него происходит вызов TRAFCOUNTER::AddUser и USERS::AddToIPIdx. Например:

traffcounter.cpp > 18:05:08 > AddUser: test

users.cpp > 18:05:08 > Add IP Idx

Первый вызов "пробегает" по всему дереву пакетов и проверяет, а не принадлежат ли какие-то из них новому юзеру. Если таковые находятся - для них выставляется соответствующий итератор и флаг. Второй вызов добавляет пользователя в индекс по ip-адресам. Эти два вызова следуют последовательно. При чем первый не блокирует добавление нового трафика. Если пользователь успеет сгенерировать хотя-бы один пакет в этот момент, а трафкаунтер успеет его принять и произвести поиск по индексу - этот пакет добавится в дерево, как не принадлежащий этому пользователю. Соответственно, его итераторы будут указывать в никуда. После этого пользователь попадает в индекс и все работает хорошо. И если пользователь остается авторизованным как минимум REMOVE_TIME времени - "плохой" пакет просто страется. А если пользователь отключается до того, как этот пакет пропадет из дерева - начинается цепочка вызовов, которая в конце концов приводит нас к TRAFFCOUNTER::DelUser. Он "пробегает" по дереву, в поисках пакетов, принадлежащих уходящему юзеру. И естественно он находит "плохой" пакет. Далее следует проверка ситуаци, когда в пакете обозначен этот пользователь, но итератор указывает не на него - это аварийная ситуация, потому что такого не может быть никогда. Тут старгейзер законно упадет, информируя о том, что в системе произошло нечто СТРАШНОЕ. Потому что такого действительно никогда не может произойти. Но это не наш случай. Условие не является сильным. Проверка по ip, userUPresent/userDPresent и итератору пропустит пакет в одном-едиснтвенном случае: если пакет действительно принадлежит пользователю, но userUPresent или userDPresent не установлен (и соответствующие итераторы невалидны). Тут-то как раз и происходит то, что описано в предыдущих постах.

Мне удалось смоделировать такую ситуацию вставкой 5-секундной задержки на завершение вызова TRAFFCOUNTER::AddUser (уже после того как все пакеты просмотрены). Далее я авторизовался в системе, но Inetaccess еще 5 секунд продолжает гореть красным. В это время я быстро сгененрировал несколько пакетов, дождалася "позеленения" Inetaccess и разавторизовался. В результате я получил такое:

traffcounter.cpp > 18:11:34 > DelUser: test

traffcounter.cpp > 18:11:34 > Counting upload packet: 192.168.1.18 -> 195.5.61.70

traffcounter.cpp > 18:11:34 > Counting upload packet: 192.168.1.18 -> 195.5.61.68

traffcounter.cpp > 18:11:34 > Counting upload packet: 192.168.1.18 -> 192.168.1.7

traffcounter.cpp > 18:11:34 > Counting download packet: 192.168.1.7 -> 192.168.1.18

traffcounter.cpp > 18:11:34 > Counting abandoned packet: 192.168.1.18 -> 195.5.61.70

traffcounter.cpp > 18:11:34 > ALARM!!!!!!!!!!!!!!!!!!!!!!!!!!!!

traffcounter.cpp > 18:11:34 > Counting abandoned packet: 192.168.1.18 -> 195.5.61.68

traffcounter.cpp > 18:11:34 > ALARM!!!!!!!!!!!!!!!!!!!!!!!!!!!!

traffcounter.cpp > 18:11:34 > Counting upload packet: 192.168.1.18 -> 192.168.1.255

users.cpp > 18:11:34 > Del IP Idx

Естественно, stargazer не упал, т.к. я поставил себе дополнительную проверку, которую порекомендовал выше. Но заодно я поставил и "ловушку", которая сработала и показала, что такая ситуация теоретически возможна.

В реальной жизни такое может происходить когда пользователь генерирует большое количество пакетов даже еще не авторизовавшись в системе.

[warzoni 7]

В реальной жизни такое может происходить когда пользователь генерирует большое количество пакетов даже еще не авторизовавшись в системе.

 

теоретически понятно, а выглядит решение в каком виде заплатки или как ? чтобы убрать такое падение раз нашлось.

[madf 279]

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

[Keen 10]

изменил.

Сутки полет нормальный, ждем следующих граблей.

(Тьфу-тьфу-тьфу. Что б небыло)

[Ork Yason 8]

кстати, я лично Максиму писал, но повторюсь здесь...

 

у мну стг с ФБ... была проблема, думаю она есть и сейчас при удалении пользователей... проблема была решена банальной правкой триггеров для удаления... кому интересно код изменений могу выложить

 

и второе...

Максим не раз говорил, что подобного рода проблемы с падениями есть только на многоядреных системах...

проблем с падениями лично у нас нет давно... на последней версии... была проблема с покраснением авторизатора у клиентов...

мы попробовали... отрубили коре-дуа у Ксеона... паралельно к этому был увеличен таум-аут для клиента... и долго и нудно оптимизировалась БД...

 

 

т.е. если есть у кого подобного рода проблемы - поделюсь опытом

[warzoni 7]

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

 

да увидил но у меня этих граблей нету , добавлю типа в список возможных граблей,а нету вазможно из за того что не авторизированный юзер не видит сервака ,типа ему токо и разрешон порт 5555. а когда авторизируетца то пожалуйста вам сэр все доступы,но и флуд пакетом он тоже не сможет делать ему помешает шепер это зделать на ограничение по пакетам. видемо из за этого нету у меня граблей.

 

p/s хотя тёмные электричиские силы есть везде *)

[warzoni 7]

кстати, я лично Максиму писал, но повторюсь здесь...

 

у мну стг с ФБ... была проблема, думаю она есть и сейчас при удалении пользователей... проблема была решена банальной правкой триггеров для удаления... кому интересно код изменений могу выложить

 

и второе...

Максим не раз говорил, что подобного рода проблемы с падениями есть только на многоядреных системах...

проблем с падениями лично у нас нет давно... на последней версии... была проблема с покраснением авторизатора у клиентов...

мы попробовали... отрубили коре-дуа у Ксеона... паралельно к этому был увеличен таум-аут для клиента... и долго и нудно оптимизировалась БД...

 

 

т.е. если есть у кого подобного рода проблемы - поделюсь опытом

 

железо опишите сваё. и систему какая стоит

[Ork Yason 8]

ксеон коре-дуо 3.2ггц, интеловая мать

центос 5, ядро 2.6.18

стг 2.4.09 или какой там последний

[madf 279]

да увидил но у меня этих граблей нету , добавлю типа в список возможных граблей,а нету вазможно из за того что не авторизированный юзер не видит сервака ,типа ему токо и разрешон порт 5555. а когда авторизируетца то пожалуйста вам сэр все доступы,но и флуд пакетом он тоже не сможет делать ему помешает шепер это зделать на ограничение по пакетам. видемо из за этого нету у меня граблей.

 

p/s хотя тёмные электричиские силы есть везде *)

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

[madf 279]

ксеон коре-дуо 3.2ггц, интеловая мать

центос 5, ядро 2.6.18

стг 2.4.09 или какой там последний

2.405 последний

[Kucher2 122]

Ну, у меня не двухядерник вроде бы - целерончик 3000, СТГ не отягощён MySQL и др. - стоит на FreeBSD 6.2. Но падения есть всё равно.

 

Может быть, раз уж баг найден, есть смысл выложить куда-нить полный архив последней пофиксеной версии СТГ?

Или подождём ещё немного?

[madf 279]

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

[den68 0]

Еще алогизмы в: void USER::ProcessNewMonth()

 

if (connected)

{

Disconnect(true);

}

DIR_TRAFF zeroTarff;

 

............

 

 

if (connected)

{

Connect(true);

}

 

 

............

 

if (connected)

{

Connect();

Disconnect();

}

[lalex 0]

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

хватит ждать уже. выкладывай. надоело уже на 2-й версии сидеть. тем более, что СТГ мой в последнее время непонятно себя ведёт. меня в тупик ставит полный (и не только меня).

[madf 279]

Еще алогизмы в: void USER::ProcessNewMonth()

 

if (connected)

{

Disconnect(true);

}

DIR_TRAFF zeroTarff;

Это не аллогизмы, это такая логика.

Обработка начала месяца - запись и сброс трафика. К стати, перед вызовом в комментарии так и написано.

 

if (connected)

{

Connect(true);

}

Тут на самом деле полезного ничего не происходит, но на всякий случай, если вдруг потом навернем логику Connect/Disconnect

Параметр true в этих двух вызовах говорит о том, что это не настоящие Connect и Disconnect. Физического отключения пользователя не происходит.

 

if (connected)

{

Connect();

Disconnect();

}

Это, я думаю, из USER::MidnightResetSessionStat? Но там тоже в параметрах указано true. Собственно, те-же яйца, что и в USER::ProcessNewMonth.

[madf 279]

хватит ждать уже. выкладывай. надоело уже на 2-й версии сидеть. тем более, что СТГ мой в последнее время непонятно себя ведёт. меня в тупик ставит полный (и не только меня).

Хочется 3-й версии?

Спешу разочаровать, ее еще долго не будет. Изменения планируемые на 3-ю версию слишком значительны.

Непонятно - это как? Раз в тупик ставит - значит с этим что-то надо делать...

Keen говорил, что периодичность повторения бага у него составляла от 2 до 48 часов - по этом и ждем 2 суток.

Неплохо было-бы, если бы Keen, Silitra и Dimension отписали.

[lalex 0]

Хочется 3-й версии?

Спешу разочаровать, ее еще долго не будет. Изменения планируемые на 3-ю версию слишком значительны.

Непонятно - это как? Раз в тупик ставит - значит с этим что-то надо делать...

3й версии не хочется. хочется стабильности. 2.0 РК3 работала 3 года как часы. проблем никогда не возникало, но в последнее время выяснил утекание трафика мимо кассы. скрипты конекта/дисконекта написаны верно и отрабатывают тоже правильно. но связь у качающего юзера (как-то очень хитро качающего, я у себя воспроизвести ситуацию не смог) не разрывается. очень странно и неясно. и периодически срабатывало правило "OUTPUT -j DROP" источник которого мной выяснен не был. ни в планировщике ни в скриптах я этим правилом не оперировал.

[madf 279]

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

[dnserg 6]

Извините , может где-то написано.

Можно ли отключать детайл стат в последней версии?

[madf 279]

Да