Summary: | СБиС++ Электронная отчeтность и документооборот 2.4.25 (демо-версия) падает при запуске | ||
---|---|---|---|
Product: | WINE@Etersoft | Reporter: | Александр Морозов <amorozov> |
Component: | Запуск ; Отладка ; Исключения | Assignee: | Александр Морозов <amorozov> |
Status: | CLOSED FIXED | QA Contact: | Andrey Vusik <night> |
Severity: | minor | ||
Priority: | P4 | CC: | kondratyuk, lav, svzhu |
Version: | 2.0 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
Whiteboard: | |||
Заявки RT: | Связано с: | ||
Дата напоминания: | |||
Bug Depends on: | |||
Bug Blocks: | 502, 5694 |
Description
Александр Морозов
2011-09-30 12:03:02 MSK
При падении СБиС создаёт файл .dmp в директории dumps. Этот файл можно открыть с помощью WinDbg и посмотреть бэктрейс командой k. Бэктрейсы получаются разные, но во всех случаях падает при выполнении RtlAllocateHeap. Попробовал в некоторых местах принудительно сбрасывать флаг HEAP_NO_SERIALIZE. Не помогло. С логом +heap запускается очень долго. Ждал 10 минут и так и не дождался. В HEAP_FindFreeBlock после выполнения ARENA_FREE *pArena = LIST_ENTRY( ptr, ARENA_FREE, entry ); в pArena иногда оказывается недействительный указатель. > С логом +heap запускается очень долго. Ждал 10 минут и так и не дождался.
Разобрался, в чём тут дело.
Функция heap_set_debug_flags при наличии +heap устанавливает флаги, включающие заполнение разных видов блоков памяти разными числами и дополнительные проверки в функциях HEAP_Validate*.
Попробовал в RtlAllocateHeap и RtlReAllocateHeap выделять в два раза больше памяти, чем запрашивается. Всё равно падает. Проблему можно обойти, если выделять памяти на 4 байта больше и возвращать сдвинутый на этот размер указатель. WINE@Etersoft 1.0 SQL 1.3.30/1.7.1-eter1.5/3 Бутылка buh/sbis/2.4.25 в eterhack Ошибки нет. Хак приводит к проблемам с запуском сервисов КриптоПро: $ ww control fixme:advapi:RegisterEventSourceW ((null),L"cpcsp"): stub fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0xc2610130,(nil),0x0001,0x00000000,0x97e4cc,(nil)): stub err:eventlog:ReportEventW L"Exception in operation." fixme:advapi:DeregisterEventSource (0xcafe4242) stub fixme:advapi:RegisterEventSourceW ((null),L"cpcsp"): stub fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0xc2610130,(nil),0x0001,0x00000000,0x97e4cc,(nil)): stub err:eventlog:ReportEventW L"Exception in DestroyCSProvider." fixme:advapi:DeregisterEventSource (0xcafe4242) stub fixme:advapi:RegisterEventSourceW ((null),L"cpcsp"): stub fixme:advapi:ReportEventW (0xcafe4242,0x0004,0x0000,0x426101f4,(nil),0x0000,0x00000000,(nil),(nil)): stub fixme:advapi:DeregisterEventSource (0xcafe4242) stub err:usbhub:initialize_usbhub failed to initialize libusb Сделал, чтобы хак работал только для sbis. Похоже, что память портится в CryptDecodeObject. Если закомментировать её содержимое и просто возвращать FALSE, то СБиС++ при запуске не падает. CryptDecodeObjectEx без CRYPT_DECODE_ALLOC_FLAG и CryptDecodeObject работают неправильно по крайней мере для X509_CERT_POLICIES, а скорее всего, и для многих других структур. Занимался данным багом CRYPT_AsnDecodeArray, если вызывается без флага CRYPT_DECODE_ALLOC_FLAG, считает, что указатель, по которому будет располагаться декодированный массив структур, проинициализирован. Баг был вызван тем, что этот указатель в ряде случаев не инициализировался. Принято. Сделал тест и отправил вместе с патчем в рассылку апстрима. |