Bug 2611

В 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

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