OberonCore
https://forum.oberoncore.ru/

DevPacker bug
https://forum.oberoncore.ru/viewtopic.php?f=23&t=1752		 Страница 1 из 1
Автор:  Александр Ильин [ Пятница, 07 Август, 2009 13:39 ]
Заголовок сообщения:  DevPacker bug
Дописал сегодня раздельчик "Автоматизация компоновки" в вики. Естественно, всё по ходу дела проверял, так как раньше не пользовался, только идея была. Нашёл баг в DevPacker, который приводил к зацикливанию на этапе чтения имён файлов, см. в самом конце статьи, патчик там же. Аналогичное зависание будет и в том случае, если команда упаковки находится в обычном документе, в самом конце его, и не завершается вьюшкой (например, EndCommander). Всем рекомендую залатать дырку и... пользоваться автоматикой. : )
Автор:  Александр Ильин [ Пятница, 07 Август, 2009 14:41 ]
Заголовок сообщения:  Re: DevPacker bug
Ещё обнаружил баг. Exe-файл, собранный автоматикой (PrivTrainingMake.Make), отказывается запускаться. Выдаёт вот такое диалоговое окошко:
Код:
---------------------------
BlackBox
---------------------------
трэп #020
- TextViews.SetCtrlDir  (pc=000001AE, fp=0022EB44)
- TextControllers.Install  (pc=000001BD, fp=0022EB58)
- StdInterpreter.CallProc  (pc=000003A6, fp=0022F5DC)
- StdInterpreter.Command  (pc=00001261, fp=0022F6EC)
- StdInterpreter.CallHook.Call  (pc=00001386, fp=0022FF50)
- Dialog.Call  (pc=00003399, fp=0022FF78)
- TextViews.Init  (pc=00004B31, fp=0022FFA0)
- TextViews.$$  (pc=0000000A, fp=0022FFB0)
---------------------------
ОК   
---------------------------

Если вставить в начало раздела инициализации модуля TextControllers вызов HALT (111), то выдаётся в точности то же самое окошко с ошибкой. Если затем слинковать вручную четырьмя коммандерами, а не одним вызовом Make, то окошко будет другое:
Код:
---------------------------
BlackBox
---------------------------
трэп #111
- TextControllers.$$  (pc=00000005, fp=0022E918)
- Kernel.InitModule  (pc=00001030, fp=0022E924)
- Kernel.ThisLoadedMod  (pc=000010AC, fp=0022E93C)
- Kernel.ThisMod  (pc=00001137, fp=0022EA54)
- Meta.Lookup  (pc=00000856, fp=0022EA78)
- StdInterpreter.CallProc  (pc=000002EB, fp=0022F50C)
- StdInterpreter.Command  (pc=00001261, fp=0022F61C)
- StdInterpreter.CallHook.Call  (pc=00001386, fp=0022FE80)
- Dialog.Call  (pc=00003399, fp=0022FEA8)
- TextViews.Init  (pc=00004B31, fp=0022FED0)
- TextViews.$$  (pc=0000000A, fp=0022FEE0)
- Kernel.InitModule  (pc=00001030, fp=0022FEEC)
---------------------------
ОК   
---------------------------
Таким образом, слинкованное вручную приложение отличается от слинкованного моей автоматикой по непонятной пока причине. Суть происходящего в том, что модуль TextControllers импортирует TextViews, а TextViews вызывает TextControllers.Install не прямо, а с помощью Dialog.Call. При этом при ручной линковке Meta.Lookup приводит к нормальной инициализации модуля (выполняется секция BEGIN -- "TextControllers.$$", куда я вставил HALT (111)), а при автоматической линковке этого не происходит, что и приводит к трапу в TextViews.SetCtrlDir (там проверка параметра на NIL, а параметр инициализируется в секции BEGIN модуля TextControllers).

Интересно так же и то, что начало стека вызовов в двух сообщениях отличается: при автоматической линковке отсутствует Kernel.InitModule. Возможно, это косвенно указывает на источник проблем. Добровольцы приглашаются к поиску бага, а у меня время на разбирательства пока закончилось.
Автор:  Илья Ермаков [ Пятница, 07 Август, 2009 15:50 ]
Заголовок сообщения:  Re: DevPacker bug
Я бы не стал линковать модули статически. Только ядро. Пусть модули идут просто припакованными. Это будет соответствовать обычному режиму работы ББ.

Если модули слинкованы, то их инициализационные секции вызывает преамбула экзешника. Может быть немного другой порядок... Хотя... Секция инициализации Kernel просто не должна отдавать управление.
Автор:  Борис Рюмшин [ Пятница, 07 Август, 2009 22:17 ]
Заголовок сообщения:  Re: DevPacker bug
Собирал (руками правда) полностью ББ (всё слинковано), со всем что есть, даже с компилятором... и ничего прёт.
Автор:  Александр Ильин [ Понедельник, 10 Август, 2009 13:10 ]
Заголовок сообщения:  Re: DevPacker bug
Выяснил, что проблема проявляется только если использовать для сборки команду DevLinker.LinkExe. Если использовать DevLinker.Link, то всё работает как должно. Документация Dev/Docu/P-S-I ("Platform-Specific Issues") как-то невнятно оговаривает, в чём разница, и когда какую команду нужно или можно использовать.

Кстати, в том же документе пример для сборки Patterns.exe не работает (ББ 1.5) по причине отсутствия модуля Sub в дистрибутиве, а также отсутствия модулей Log и StdApi в списке для компоновки.
Автор:  Илья Ермаков [ Понедельник, 10 Август, 2009 14:00 ]
Заголовок сообщения:  Re: DevPacker bug
LinkExe следует использовать для того случая, когда не требуется динамическая загрузка модулей. Стандартный полный ББ всегда надо обычным Link...
Автор:  Александр Ильин [ Понедельник, 10 Август, 2009 14:07 ]
Заголовок сообщения:  Re: DevPacker bug
Илья Ермаков писал(а):
LinkExe следует использовать для того случая, когда не требуется динамическая загрузка модулей. Стандартный полный ББ всегда надо обычным Link...
Так мне и не требуется динамика. Я полный список статически перечислил. Наоборот, если будет подхватывать с диска иные версии, это может поломать exe-шник (например, если Config будет не тот).
Автор:  Илья Ермаков [ Понедельник, 10 Август, 2009 14:29 ]
Заголовок сообщения:  Re: DevPacker bug
Да, но, видимо, графический фреймворк ББ рассчитан таки именно на линковку под динамику. При линковке LinkExe порядок инициализации (это хуков касается особенно) меняется.
Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/