принудительная синхронизация / проблемы синхронизации / PP

Официальный сервер Ragnarok On-Line в России - https://ru.4game.com/ro/install/

Модератор: 4epT

Правила форума
ВНИМАНИЕ: реклама сторонних ботов запрещена! Всякие плюшки - можно :)
japplegame
Профессионал
Сообщения: 272
Зарегистрирован: Вс ноя 05, 2006 2:03 pm

Сообщение japplegame » Пт янв 12, 2007 10:46 am

kLabMouse писал(а):japplegame
В любом случае у нас есть данные где он возник. Тее входные данные.
Неуже-ли трудно зделать сравнение клиента и дллки в данном конкретном случае при конкретно указаных входных данных?
Не ужели так трудно внимательно читать посты:
japplegame писал(а):Заипали вы уже с этой 0E. Тестил я ее вдоль и поперек. Причем брал синки и аккИД из лога глюков, который мне прислали. Никуя проблем с этими значениями нет...
И саму Call16 проверял несколько раз. Так сказать, в лабораторных условиях, все прекрасно совпадает.
Иногда вообще творятся странные вещи дебаггер в плагине показывает пакет, который не совпадает с оригинальным, но когда входные данные для этого пакета я передал Jerry он в совей "лаборатории" получил совершенно правильный пакет, совпадающий с оригиналом. Что за мистика не пойму.

DInvalid
Грамотный
Сообщения: 368
Зарегистрирован: Вт ноя 14, 2006 4:54 pm

Сообщение DInvalid » Пт янв 12, 2007 2:57 pm

japplegame писал(а): Так сказать, в лабораторных условиях, все прекрасно совпадает.
Иногда вообще творятся странные вещи дебаггер в плагине показывает пакет, который не совпадает с оригинальным, но когда входные данные для этого пакета я передал Jerry он в совей "лаборатории" получил совершенно правильный пакет, совпадающий с оригиналом. Что за мистика не пойму.
Это не мистика, такое может быть если результат работы программы зависит не только от текущих входных параметров, но и от предидущих рез-тов работы, и на стенде тест функции с этими же входными данными даст правильный ответ, так как все внутренние буферы и переменные обнуленны;
А во время реальной работы возникает предположим такое состояние этих самых внутренних буферов и переменных что они влияют на результат, значит просто прогоном и фикасацией входных данных при которых произошла ошибка недостаточно;
Надо сохранить все внутренние переменные на момент времени формирования пакета с ошибкой; и потом воспроизводить это состояние на тестовом стенде и подавать входные данные...

П.С. japplegame как с тобой связаться, есть кое что что надо попробовать сделать, похоже я нашел способ воспроизвести "глюк"

Аватара пользователя
kLabMouse
Профессионал
Сообщения: 4776
Зарегистрирован: Вс ноя 05, 2006 4:32 pm

Сообщение kLabMouse » Пт янв 12, 2007 6:28 pm

DInvalid
Воспроизвести можно двумя способами:
1) Взять данные именно для глюкнутого пакета (но оно пашет)
2) Попробовать воспроизвести все пакетики с самого начала. ТЕ со старта.

DInvalid
Грамотный
Сообщения: 368
Зарегистрирован: Вт ноя 14, 2006 4:54 pm

Сообщение DInvalid » Пт янв 12, 2007 11:48 pm

japplegame писал(а):И саму Call16 проверял несколько раз. Так сказать, в лабораторных условиях, все прекрасно совпадает.
Опыты на животных :evil: показали, что стек при вызове
dword hashData = Call16( serverMapSync, clientSync, clientAccId, type );
совпадает как при нормальном состоянии, так и в состоянии "глюка":
15A6E97A
03B66EB9
XXXXXXX
01C00098

А вот возвращаемое значение в EAX - разное. :ROFL:

Вывод: скорее всего это не "косяк Перла", и не "ошибка из за лагов", возможно это проблема в Call16

japplegame
Профессионал
Сообщения: 272
Зарегистрирован: Вс ноя 05, 2006 2:03 pm

Сообщение japplegame » Сб янв 13, 2007 1:48 am

Я уже заканчиваю новый ropp.dll в котором вообще нет Call16. Вместо этого вызывается оригинал из ragexe.exe

DInvalid
Грамотный
Сообщения: 368
Зарегистрирован: Вт ноя 14, 2006 4:54 pm

Сообщение DInvalid » Сб янв 13, 2007 2:15 am

japplegame писал(а):Я уже заканчиваю новый ropp.dll в котором вообще нет Call16. Вместо этого вызывается оригинал из ragexe.exe
Интересно девки пляшут! (с)
Т.е.
1) найти глюк в текущей версии вам уже не интересно? тем более сейчас, когда найден способ вызывть сбой - нужно просто отладить dll - посмотерть где что не так при сбое - может быть таблицы констант портятся или что то подобное.
2) dll будет запускать ragexe.exe? а как же переносимость? а память и системные требования?

В конце концов, вы столько говорили что уверены в правильности этой ф-ции, и вдруг ...

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

Аватара пользователя
kLabMouse
Профессионал
Сообщения: 4776
Зарегистрирован: Вс ноя 05, 2006 4:32 pm

Сообщение kLabMouse » Сб янв 13, 2007 3:05 am

DInvalid писал(а):В обшем я вас призываю разобраться сначала с тем что есть а потом применять другие методы...
Согласен. Раз и навсегда выловить тот Грёбаный Глюк.

japplegame
Профессионал
Сообщения: 272
Зарегистрирован: Вс ноя 05, 2006 2:03 pm

Сообщение japplegame » Сб янв 13, 2007 1:49 pm

Это один из способов найти глюк. Если сбои не исчезнут, то можно отстать от хеш-функций, раз и навсегда.
Это вообще тестовое решение, а не альтернатива текущему. Соответственно вопросы о переносимости и системных ресурсах отпадают автоматически. Хотя насчет производительности, dll не запускает ragexe в полном смысле этого слова, запускать-то запускает, но 99% времени поток находится в замороженном состоянии и ресурсов не ест, кроме пары-тройки мегабайт оперативы в худшем случае.
В конце-концов исходники либы лежат в СВН, всем особо умным предлагаю взять их в зубы и искать глюк так как им захочется.

DInvalid
Грамотный
Сообщения: 368
Зарегистрирован: Вт ноя 14, 2006 4:54 pm

Сообщение DInvalid » Сб янв 13, 2007 1:59 pm

japplegame писал(а):Это один из способов найти глюк. Если сбои не исчезнут, то можно отстать от хеш-функций, раз и навсегда.
Это вообще тестовое решение, а не альтернатива текущему. Соответственно вопросы о переносимости и системных ресурсах отпадают автоматически. Хотя насчет производительности, dll не запускает ragexe в полном смысле этого слова, запускать-то запускает, но 99% времени поток находится в замороженном состоянии и ресурсов не ест, кроме пары-тройки мегабайт оперативы в худшем случае.
В конце-концов исходники либы лежат в СВН, всем особо умным предлагаю взять их в зубы и искать глюк так как им захочется.
Ндя, "всем особо умным", понимаешь, копаться в исходниках не зная что они из себя представляют, как то затруднительно.

Эппл! Я могу воспроизвести глюк, понимаешь? Я могу заставить dll выдать неправильный пакет, что я и проделал, при этом поставил бряк на вызов
dword hashData = Call16( serverMapSync, clientSync, clientAccId, type );
в Оле, данные передаваемые ей одинаковы, а вот ответ разный!!!
Значит глюк точно в ней!

Тебя уже который раз спрашиваю как с тобой связаться что бы обсудить это; а ты всместо этого обижаешься.
Да я понимаю что ты будешь запускать РО, делать что то типа SuspendThread и внедряться в него но оно надо?

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

П.С.
"Это один из способов найти глюк. Если сбои не исчезнут, то можно отстать от хеш-функций, раз и навсегда."
ТОесть ты хочешь однозначно исключить ф-ю Call16 из подозрений?
Я пишу еще раз, значение возвращаемое при одних и тех же данных этой ф-ей разное в случает просто вызова энкоде и в случае вызова ее в "глючном" состоянии.
Я написал программу которая прсит лог и вызывает CreateAtk($Packet, unpack("L1", $ID3), 0x07);, и с ее помощью воспроизводится глюк!
Если просто вызвать CreateAtk, то формируется правильный пакет, но вызов ее после определнных вызовов приводит к генерации неправильного пакета!

Аватара пользователя
kLabMouse
Профессионал
Сообщения: 4776
Зарегистрирован: Вс ноя 05, 2006 4:32 pm

Сообщение kLabMouse » Сб янв 13, 2007 3:01 pm

DInvalid писал(а):Я написал программу которая прсит лог и вызывает CreateAtk($Packet, unpack("L1", $ID3), 0x07);, и с ее помощью воспроизводится глюк!
Если просто вызвать CreateAtk, то формируется правильный пакет, но вызов ее после определнных вызовов приводит к генерации неправильного пакета!
ЫЫ. Сиквенс передаваемых в функцию данных можеш зспостить?

japplegame
Вот мне одно интересно. Помниш глюк с 02 функцией? Так вот. там при одинаковых входных значенияч выдавался разный результат. Полагаю что подобный баг и здесь.

japplegame
Профессионал
Сообщения: 272
Зарегистрирован: Вс ноя 05, 2006 2:03 pm

Сообщение japplegame » Сб янв 13, 2007 3:45 pm

kLabMouse писал(а):japplegame
Вот мне одно интересно. Помниш глюк с 02 функцией? Так вот. там при одинаковых входных значенияч выдавался разный результат. Полагаю что подобный баг и здесь.
Там была другая ситуация. Изначально func2 был правильный, а потом я внес туда ошибку случайно. И тестилка мгновенно выдала несоответствие. А вот на функцию 0E она ну никак не дает ошибок. Не знаю почему.

japplegame
Профессионал
Сообщения: 272
Зарегистрирован: Вс ноя 05, 2006 2:03 pm

Сообщение japplegame » Сб янв 13, 2007 3:47 pm

DInvalid, скажи тогда как воспроизвести баг.

DInvalid
Грамотный
Сообщения: 368
Зарегистрирован: Вт ноя 14, 2006 4:54 pm

Сообщение DInvalid » Сб янв 13, 2007 3:56 pm

kLabMouse писал(а): ЫЫ. Сиквенс передаваемых в функцию данных можеш зспостить?
В каком виде? Я сейчас сокращаю длину этой последовательностти, удаляя предшествуещие вызовы блоками по синкам.
DInvalid, скажи тогда как воспроизвести баг.
Я передал Jerry программу которая парсит лог и вызывает ф-ю;
Для воспроизведения бага надо подать вызывать ф-ю с определнной последовательностью входных данных, я сейчас ищу эту последовательность, так как лог с самого старта и д глюка -это сотни строчек, явно ее можно сократить.

japplegame
Профессионал
Сообщения: 272
Зарегистрирован: Вс ноя 05, 2006 2:03 pm

Сообщение japplegame » Сб янв 13, 2007 4:03 pm

Этот баг наблюдается только с функцией 0E? Есть какая-то корреляция? Типа, как только вызывается 0E, так сразу шлются разные пакеты?

Аватара пользователя
kLabMouse
Профессионал
Сообщения: 4776
Зарегистрирован: Вс ноя 05, 2006 4:32 pm

Сообщение kLabMouse » Сб янв 13, 2007 4:24 pm

japplegame
Самое интересное в том что. 0D пашет норм. А вот 0E нет. Хотя заметь что они спареные и используют один и тот-же алгоритм.
Хотя может Я ошибаюсь.

Ответить