Просим протестировать программу СТМ-Декларант. Дистрибутив находится по этой ссылке ftp://ftp.ctm.ru/ctm/DCL/FULL/DCL.ZIP Дополнительно сообщаем, что после тестирования у нас процесс установки проходит нормально, а вот во время загрузки программы происходит её <зависание>, при загрузке <главного окна> (тестирование проводилось на дистрибутивах Debian и OpenSuse).
Останавливается при загрузке главного окна. fixme:tab:TAB_SetCurFocus Should set input focus fixme:winhttp:WinHttpCheckPlatform stub err:seh:setup_exception_record stack overflow 376 bytes in thread 0009 eip 660ce703 esp 002311b8 stack 0x230000-0x231000-0x330000
какая бутылка? что значит останавливается? зависает? ожидает чего-то? или вываливается?
(In reply to comment #2) > какая бутылка? > что значит останавливается? зависает? > ожидает чего-то? или вываливается? > Не знаю пр какую "бутылку" идёт речь(наверное это вопрос к Этерсофту, но как в версии 1.0.8 так и в версии 1.0.9, программа "почти" загрузившись доходит до "Загрузки главного окна", и останавливается!!!...НЕ "вываливается" а просто останавливается!...И висит неопределенное количество времени! В консоли если не ошибаюсь написано именно то что указанно в комментарии №1, по данной баге. Что дальше пока не понятно!?...
Бутылка deklarant
запускать следует через winexp В текущей версии (на cellar) возникает ошибка при входе в critical section: err:ntdll:RtlpWaitForCriticalSection section 0x110570 "?" wait timed out in thread 0032, blocked by 0014, retrying (60 sec) При тестировании на последней версии (ещё нет в сборке) загрузка идёт значительно дальше. Программа падает, но само падение происходит как-то странно: в консоле сообщение: wine: Unhandled page fault on read access to 0x00000224 at address 0x7bc3daa4 (thread 0009), starting debugger... но сам дебаггер не запускается! если отлаживать по каналу seh, то после этого появляется ещё несколько сообщений: trace:seh:raise_exception code=c0000005 flags=0 addr=0x7bc3daa4 trace:seh:raise_exception info[0]=00000000 trace:seh:raise_exception info[1]=00000224 trace:seh:raise_exception eax=00000230 ebx=7bc83440 ecx=00000224 edx=01c44638 esi=0011003c edi=00000030 trace:seh:raise_exception ebp=0032e748 esp=0032e744 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00210293 trace:seh:call_stack_handlers calling handler at 0x7bc38360 code=c0000005 flags=0 trace:seh:call_stack_handlers handler at 0x7bc38360 returned 2 trace:seh:call_stack_handlers calling handler at 0x113daeb6 code=c0000005 flags=10 trace:seh:call_stack_handlers handler at 0x113daeb6 returned 1 trace:seh:call_stack_handlers handler at 0x113daeb6 returned 1 trace:seh:call_stack_handlers calling handler at 0x113daeb6 code=c0000005 flags=10 ...
С учётом фикса #2357 баги - нужно проверить. Если не исправиься, ждать #2399
(In reply to comment #5) > запускать следует через winexp > > В текущей версии (на cellar) возникает ошибка > при входе в critical section: > err:ntdll:RtlpWaitForCriticalSection section 0x110570 "?" wait timed out in > thread 0032, blocked by 0014, retrying (60 sec) > > При тестировании на последней версии (ещё > нет в сборке) загрузка идёт значительно > дальше. > Программа падает, но само падение > происходит как-то странно: > в консоле сообщение: > wine: Unhandled page fault on read access to 0x00000224 at address 0x7bc3daa4 > (thread 0009), starting debugger... > > но сам дебаггер не запускается! Подтверждаю. Воспроизвел на новой сборке.
(In reply to comment #6) > С учётом фикса #2357 баги - нужно проверить. > Если не исправиься, ждать #2399 > Проверил на текущей версии git - поведение изменилось. теперь повисает на: err:ntdll:RtlpWaitForCriticalSection section 0x110570 "?" wait timed out in thread 003d, blocked by 0039, retrying (60 sec)
С критическими секциями несколько правок уже вошли в релиз. Нужно проверить, как оно себя ведёт сейчас. Станислав, Ваш комментарий тоже приветствуется :)
На текущей сборке libwine-1.0.9-alt34.1 wine-1.0.9-alt34.1 wine-etersoft-sql-1.0.9-alt0.M41.13 Так же вещается на загрузке главного окна. В консоли: wine: Unhandled page fault on read access to 0x00000224 at address 0x7bc43670 (thread 0009), starting debugger... Если приатачиться к процессу через winedbg и посмотреть bt, то такая картина: Backtrace: =>1 0xb7e560ff __libc_read+0x3f() in libpthread.so.0 (0x0032df48) 2 0x7bc6b663 NTDLL_wait_for_multiple_objects+0x223() in ntdll (0x0032e058) 3 0x7bc6b952 NtWaitForMultipleObjects+0x62() in ntdll (0x0032e088) 4 0x7b88f6e2 WaitForMultipleObjectsEx+0x102() in kernel32 (0x0032e1c8) 5 0x7b88f8dc WaitForSingleObject+0x3c() in kernel32 (0x0032e1e8) 6 0x7b843ac4 UnhandledExceptionFilter+0x84() in kernel32 (0x0032e248) err:dbghelp:pe_load_dbg_file Couldn't find .DBG file "DLL\\MSVBVM60.dbg" ("") 7 0x6601f854 in msvbvm60 (+0x1f854) (0x0032ff00) 8 0x004014b6 in dcl (+0x14b6) (0x0032ffe8) 9 0xb7e69c97 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000)
Демо-версию реально запустить, если сборку вайна проводить с другими флагами (оптимизация, как в случае с WinPost?). В моём рабочем репозитории работает, причём лучше использовать нативные ole/rpc. Зависимости от WINDOWS_VERSION пока не установил.
Флаг -O2 не имеет отношения к проблеме. Декларант запускается и работает с ним.
У меня для обновленного репозитория декларант запускается. Очевидно, при запуске какого-то стороннего процесса при своём старте тот падает с бэктрейсом. =>0 0x84fdbbb5 load_driver_module+0x1fe(name=0x810111c0) [/srv/mibori/Projects/wine/programs/winedevice/device.c:110] in winedevice (0x842f6638) 1 0x84fdc4b8 load_driver+0x3f0(drv_name=0x81011098, driver_obj=0x842f6924, driver_extension=0x842f69cc) [/srv/mibori/Projects/wine/programs/winedevice/device.c:242] in winedevice (0x842f68a8) 2 0x84fdcc70 handle_loading_request+0x189(pipe=0x50, driver_obj=0x842f6924, driver_extension=0x842f69cc, drv_name=0x842f69ec, event_name=0x842f69e8) [/srv/mibori/Projects/wine/programs/winedevice/device.c:377] in winedevice (0x842f68f8) 3 0x84fdd138 driver_thread+0x79(pipe=0x50) [/srv/mibori/Projects/wine/programs/winedevice/device.c:468] in winedevice (0x842f69f8) 4 0x7bc7f11e call_thread_entry_point+0xe() in ntdll (0x842f6a08) 5 0x7bc7f1cf call_thread_func+0xaf(rtl_func=0x84fdd0bf, arg=0x50) [/srv/mibori/Projects/wine/dlls/ntdll/thread.c:395] in ntdll (0x842f6ac8) 6 0x7bc7f44b start_thread+0x1d3(info=0x81ffcfb8) [/srv/mibori/Projects/wine/dlls/ntdll/thread.c:457] in ntdll (0x842f73c8) 7 0xb7dd2daa start_thread+0xaa() in libpthread.so.0 (0x842f74b8) 8 0xb7d46dde __clone+0x5e() in libc.so.6 (0x00000000) 0x84fdbbb5 load_driver_module+0x1fe [/srv/mibori/Projects/wine/programs/winedevice/device.c:110] in winedevice: movl $0x0,0xa0(%eax) несмотря на это декларант продолжает запускаться до рабочего состояния. И далее работает на превый взгляд нормально, не создавая исключений.
при выходе наблюдается исключение: =>0 0x7ee0f585 call_hook_WtoA+0x37(proc=0xffde0000, id=4, code=0, wparam=1, lparam=3341300) [/srv/mibori/Projects/wine/dlls/user32/hook.c:251] in user32 (0x0032f798) 1 0x7ee0f8d4 call_hook_proc+0xe4(proc=0xffde0000, id=4, code=0, wparam=1, lparam=3341300, prev_unicode=1, next_unicode=0) [/srv/mibori/Projects/wine/dlls/user32/hook.c:301] in user32 (0x0032f7d8) 2 0x7ee0fd90 call_hook+0x32e(info=0x32f87c, code=0, wparam=1, lparam=3341300) [/srv/mibori/Projects/wine/dlls/user32/hook.c:382] in user32 (0x0032f848) 3 0x7ee10016 HOOK_CallHooks+0x266(id=4, code=0, wparam=1, lparam=3341300, unicode=1) [/srv/mibori/Projects/wine/dlls/user32/hook.c:431] in user32 (0x0032fba8) 4 0x7ee38892 call_window_proc+0x8b(hwnd=0x10028, msg=2, wparam=0, lparam=0, unicode=1, same_thread=1, mapping=574124032) [/srv/mibori/Projects/wine/dlls/user32/message.c:1640] in user32 (0x0032fc08) 5 0x7ee3b514 send_message+0x13f(info=0x32fc78, res_ptr=0x32fca4, unicode=1) [/srv/mibori/Projects/wine/dlls/user32/message.c:2486] in user32 (0x0032fc58) 6 0x7ee3b914 SendMessageW+0x54(hwnd=0x10028, msg=2, wparam=0, lparam=0) [/srv/mibori/Projects/wine/dlls/user32/message.c:2610] in user32 (0x0032fca8) 7 0x7ee6f517 WIN_SendDestroyMsg+0x70(hwnd=0x10028) [/srv/mibori/Projects/wine/dlls/user32/win.c:1460] in user32 (0x0032fd08) 8 0x7ee6f944 DestroyWindow+0x33c(hwnd=0x10028) [/srv/mibori/Projects/wine/dlls/user32/win.c:1564] in user32 (0x0032fd58) 9 0x7eab680a apartment_release+0x191(apt=0x123208) [/srv/mibori/Projects/wine/dlls/ole32/compobj.c:376] in ole32 (0x0032fdb8) 10 0x7eab8acf CoUninitialize+0x149() [/srv/mibori/Projects/wine/dlls/ole32/compobj.c:1244] in ole32 (0x0032fe08) 11 0x7eae2ef0 OleUninitialize+0xdd() [/srv/mibori/Projects/wine/dlls/ole32/ole2.c:263] in ole32 (0x0032fe38) 12 0x6600e933 in msvbvm60 (+0xe933) (0x0032fe54) 13 0x6600c54b in msvbvm60 (+0xc54b) (0x00000000)
с комбинациями -march=i586 -mtune=i686 -march=i586 -mtune=i686 падения не происходит. также падения не происходит, если CFLAGS отсутствует. нужно попытаться запустить декларант на пересобранных исходниках, сборка из которых используется на сервере, до того как из них был оформлен rpm. если падения происходить не будет, то в падении виновато создание rpm. если будет -- виновата сборка бинарников. пока считаю, что ситуация WinPost и Декларантом -- это соверешенно разные проблемы.
По cовету Константина, в качестве серверных исходников было взято то, что находится в папке /srv/lav/BUILD/wine-1.0.9/ падение декларанта происходит. но в данной папке нет исходников.
продолжаю искать исходники вайна. в /srv/lav/Projects/wine-9 нашел собранные исходники, на которых воспроизводится падение. далее пытаюсь пересобрать исходники у себя. завершается с ошибкой checking for isnan... yes checking whether we need to define __i386__... no configure: creating ./config.status configure: WARNING: unrecognized options: --disable-dependency-tracking, --without-included-gettext, --enable-dll, --enable-opengl make: *** Нет правила для сборки цели `Makefile.in', требуемой для `Makefile'. Останов. [mibori@builder wine]$ make clean running CONFIG_SHELL=/bin/sh /bin/sh ./configure --with-opengl CFLAGS=-D_FORTIFY_SOURCE=2 -g --no-create --no-recursion ./configure: line 1855: confdefs.h: Permission denied ./configure: line 1860: confdefs.h: Permission denied ./configure: line 1865: confdefs.h: Permission denied ./configure: line 1870: confdefs.h: Permission denied ./configure: line 1875: confdefs.h: Permission denied checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking whether make sets $(MAKE)... ./configure: line 2425: conftest.make: Permission denied no checking for gcc... gcc ./configure: line 2793: conftest.c: Permission denied ./configure: line 2796: conftest.c: Permission denied ./configure: line 2797: conftest.c: Permission denied checking for C compiler default output file name... sed: can't read conftest.c: No such file or directory configure: error: in `/srv/lav/Projects/wine-9': configure: error: C compiler cannot create executables See `config.log' for more details. make: *** [config.status] Ошибка 77 окончилось с ошибкой. Нет никакой информации, что старые бинарники и .o/.so-шники удалены. несмотря на это попробую запустить build_wine.sh сборка проходит успешно. в процессе запуска декларант падает с сообщением: err:seh:setup_exception_record stack overflow 832 bytes in thread 0009 eip 7bc70ebd esp 00230ff0 stack 0x230000-0x231000-0x330000 err:heap:HEAP_GetPtr Invalid heap 0x110000! err:heap:HEAP_GetPtr Invalid heap 0x110000! err:heap:HEAP_GetPtr Invalid heap 0x110000! err:heap:HEAP_GetPtr Invalid heap 0x110000! err:heap:HEAP_GetPtr Invalid heap 0x110000! err:heap:HEAP_GetPtr Invalid heap 0x110000! err:heap:HEAP_GetPtr Invalid heap 0x110000! err:heap:HEAP_GetPtr Invalid heap 0x110000! err:heap:HEAP_GetPtr Invalid heap 0x110000! err:ntdll:RtlpWaitForCriticalSection section 0x7bca3520 "exception.c: vectored_handlers_section" wait timed out in thread 0027, blocked by 0009, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7bca3640 "loader.c: loader_section" wait timed out in thread 0024, blocked by 0027, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7bca3520 "exception.c: vectored_handlers_section" wait timed out in thread 0027, blocked by 0009, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7bca3520 "exception.c: vectored_handlers_section" wait timed out in thread 0024, blocked by 0009, retrying (60 sec) далее три варианта: 1. подправить цель clean 2. полазить по папкам в поисках других исходников вайна 3. принять, что данный вайн является тем самым вайном, что используется на сервере, и начать разбирать падение.
из данной ситуации скорее всего следует, что проблема не в сборке rpm-пакета, а в компиляции. Однако без очистки исходников от бинарников, нельзя точно опровергать, что компиляция на одной машине не порождает ошибку, а компиляция на другой порождает.
для исходников /srv/lav/Projects/wine-9 работает make distclean сборка после этого проходит успешно. после сборки декларант падает с сообщением wine: Unhandled page fault on read access to 0x00000224 at address 0x7bc44443 (thread 0009), starting debugger... err:ntdll:RtlpWaitForCriticalSection section 0x110048 "heap.c: main process heap section" wait timed out in thread 0023, blocked by 0009, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7bca3640 "loader.c: loader_section" wait timed out in thread 0025, blocked by 0023, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7bca3640 "loader.c: loader_section" wait timed out in thread 0046, blocked by 0023, retrying (60 sec) ... итак у меня исходники двух вайнов (чего и добивался): после сборки первый из них попрождает исключение в декларанте, второй его не порождает (декларант работает) далее два варианта: 1. нужно смотреть различия: а) файлов участвующих в сборке и исходников б) логов сборки 2. нужно анализировать проявляемое исключение в нерабочем вайне пойдем по наименьшему сопротивлению: 1.-б) для 2., по поводу причин ошибки. судя по разным сообщениям, получаемое исключение может следовать из проблемы выделения пространства под кучу (это вполне может быть ошибка какого-нибудь HeapAlloc). Вобщем случае всё, что видно говорит о том, что это ошибка не работы с памятью, а с ее выделением.
для 1.0.10 проблема не проявляется (падения не происходит)
