В основном бага воспроизводится при сканировнии ШК с проброшенного порта. Появляется как в 1с77 так и 1с81. Задержка - при сканировании некоторое время в 1с не передается никокой информации, а потом через секунды 3 выдается вся информация, поступившая со сканера за это время (в случаи если мы сканируем несколько ШК подряд). Потеря данных - это когда со сканера поступает код по половинке или частично. При этом, все тесты в атоле проходят нормально, никаких нареканий.
В 1с77 проблема с потерей данных решается увеличением чувствительности до 30 мс.
Баг воспроизводится (у меня) как с проброшеннего, так и с локального ком порта - проброс в пропатченном (куррент) вайне выполнен похоже окончательно и надежно - дело вроде как не в пробросе. Попробую в понедельник в трех точках на четырех ККМ+СканШК в "Боевых усл - в т.ч. один "проброшен"" (в тестовых трудно что-то сказать - вроде задержка уменьшилась, но не пропала) чуствительность 30 в атол.драйвере - к вечеру рез-таты, но предварит. анализ думаю рано радоваться - и при чуствительности 0 по умолчанию вроде (у меня) данные не терялись. В сборках куррент .24 или .25 есть изменения по теме? В боевых куррент.20
(In reply to comment #2) себе: > Баг воспроизводится (у меня) как с > проброшеннего, так и с локального ком порта Реч идет только о задержке! > вроде задержка уменьшилась, но не > пропала) чуствительность 30 в атол.драйвере результаты задержек от сканирования до момента появления "выполняется обработка" в инф.строке 1с при спокойной работе на второй (ремсериал) кассе (мало покупателей - пробитых чеков) в "боевых условиях" в течение часа (сек): 2,2,2,3,1,3,2,2,4,3,2,1,2,3,2,2,2,3 (на "глазок" - считалось "ираз", "идва"...) Сервер fedora9 DualCore1.8GHz RAM1Gb FreeNX(RX) > думаю рано радоваться надо что-то делать !!! > куррент.20
Из профайлеров я нагуглил gprof, cprof, oprofile. gprof непонятно, как использовать с wine. Собрал ntdll с флагом -pg, запустил программку через ww, gmon.out нигде не нашёл. К cprof даже прилагается патч для wine, но сам cprof собрать не удалось. Да и файлы в архиве с исходниками 2001-го года, так что не факт, что с теперешним wine будет работать. В wine-devel советуют oprofile. Он меряет не одно приложение, а всё, что запущено в системе, то есть видимо надо чтобы на компьютере кроме измеряемого wine с 1С не было запущено ещё несколько других потребляющих ресурсы программ (ещё несколько wine-ов, например). Кроме того, запускать его надо под root.
Created attachment 828 [details] Лог, полученный с помощью oprofile во время сканирования Судя по всему, профайлер в данном случае не поможет
Created attachment 829 [details] Лог с закомментированным использованием mcache в wine_server_call
Добавил вывод читаемых ReadFile штрихкодов и временных отметок в виде [секунды:микросекунды] (на основе патча Peter Urbanec). Штрихкоды сразу же выводятся в лог, а MessageBox может появиться и через 10 секунд.
Created attachment 840 [details] WINEDEBUG=+timestamps,+file,+relay ww 1cv7s.exe 2>&1 | egrep '(ReadFile buffer|Call user32.MessageBoxA)' Штрихкод 9785941578511
Проблема оказалась связана с увеличением таймаута одного из таймеров с помощью функции etersoft_fixtimer. Установка этого таймера в логе: 0009:Call user32.SetTimer(00000000,00000000,000000c8,2200e170) ret=2200fb7d 0009:Ret user32.SetTimer() retval=00007fff ret=2200fb7d Проблему можно решить с помощью патча diff --git a/dlls/user32/message.c b/dlls/user32/message.c index 952ed09..16d0d4e 100644 --- a/dlls/user32/message.c +++ b/dlls/user32/message.c @@ -3589,9 +3589,12 @@ UINT_PTR WINAPI SetTimer( HWND hwnd, UINT_PTR id, UINT timeout, TIMERPROC proc ) if (proc) winproc = WINPROC_AllocProc( (WNDPROC)proc, NULL ); - LOADETER_FUNC(etersoft_fixtimer); - if (etersoft_fixtimer) - etersoft_fixtimer(id, &timeout); + if (!(id == 0 && timeout == 200)) + { + LOADETER_FUNC(etersoft_fixtimer); + if (etersoft_fixtimer) + etersoft_fixtimer(id, &timeout); + } SERVER_START_REQ( set_win_timer ) { Возможно, правильнее поправить etersoft_fixtimer.
Исправлено в закрытой части, будет в сборке eter10
Для тех, кто не пользуется багзиллой или не умеет пользоваться групповым редактированием при поиске, закрываем задачи, которые они должны были принять.
