Сообщение Re[3]: падает все подряд после замены dll-ки в appinit_dlls от 10.11.2016 15:45
Изменено 10.11.2016 15:49 Carc
Здравствуйте, ksd, Вы писали:
ksd>используется. а что рантайм? она статически линкуется. пишуть, что можно пользоваться только kernel32, остальное еще не загружено. ну, после перезагрузки винды же все нормально?
Если есть какие-нить статические переменные уровня класса или в cpp-файле, то по идее их как раз должна иницилизировать рантайм. А в момент загрузки, если рантайм еще не инициализирована, и есть какие-то обращения к таким переменным, то чего в этом случае произойдет один бог его знает. Может быть в этом дело?
Я нечто подобное видел, правда в exe-шнике. Но в нем для пущей липосакции был по максимуму убран рантайм. Дык вот после подключения какого-то левого модуля, у которого в cpp водился std::string статический на класс, exe-шник начал валиться прям на старте с Access Violation. Вылечил заменой всех объектных переменных вроде std::string на скалярные типы данных, вроде char[].
Насколько я тогда понял, компилятор просто размещал такие данные в data-секции exe-шника и заранее "знал" их как иницилизировать. И проблема исчезла. Там вроде как получалось, что этот статический std::string на своей инициализации выделял память, и что-то туда писал. Без рантайма на старте в релизе это ессесна не работало. А когда я туда сложил скалярные типы с заданным размером, то вроде как получалось, что компилятор заранее знал размер и чем инициализировать, поэтому обходился без инициализации с рантаймом.
Может наведет на какую-нить мысль?
ksd>используется. а что рантайм? она статически линкуется. пишуть, что можно пользоваться только kernel32, остальное еще не загружено. ну, после перезагрузки винды же все нормально?
Если есть какие-нить статические переменные уровня класса или в cpp-файле, то по идее их как раз должна иницилизировать рантайм. А в момент загрузки, если рантайм еще не инициализирована, и есть какие-то обращения к таким переменным, то чего в этом случае произойдет один бог его знает. Может быть в этом дело?
Я нечто подобное видел, правда в exe-шнике. Но в нем для пущей липосакции был по максимуму убран рантайм. Дык вот после подключения какого-то левого модуля, у которого в cpp водился std::string статический на класс, exe-шник начал валиться прям на старте с Access Violation. Вылечил заменой всех объектных переменных вроде std::string на скалярные типы данных, вроде char[].
Насколько я тогда понял, компилятор просто размещал такие данные в data-секции exe-шника и заранее "знал" их как иницилизировать. И проблема исчезла. Там вроде как получалось, что этот статический std::string на своей инициализации выделял память, и что-то туда писал. Без рантайма на старте в релизе это ессесна не работало. А когда я туда сложил скалярные типы с заданным размером, то вроде как получалось, что компилятор заранее знал размер и чем инициализировать, поэтому обходился без инициализации с рантаймом.
Может наведет на какую-нить мысль?
Re[3]: падает все подряд после замены dll-ки в appinit_dlls
Здравствуйте, ksd, Вы писали:
ksd>используется. а что рантайм? она статически линкуется. пишуть, что можно пользоваться только kernel32, остальное еще не загружено. ну, после перезагрузки винды же все нормально?
Если есть какие-нить статические переменные уровня класса или в cpp-файле, то по идее их как раз должна иницилизировать рантайм. А в момент загрузки, если рантайм еще не инициализирована, и есть какие-то обращения к таким переменным, то чего в этом случае произойдет один бог его знает. Может быть в этом дело?
Я нечто подобное видел, правда в exe-шнике. Но в нем для пущей липосакции был по максимуму убран рантайм. Дык вот после подключения какого-то левого модуля, у которого в cpp водился std::string статический на класс, exe-шник начал валиться прям на старте с Access Violation. Вылечил заменой всех объектных переменных вроде std::string на скалярные типы данных, вроде char[].
Насколько я тогда понял, компилятор просто размещал такие данные в data-секции exe-шника и заранее "знал" их как иницилизировать. И проблема исчезла. Там вроде как получалось, что этот статический std::string на своей инициализации выделял память, и что-то туда писал. Без рантайма на старте в релизе это ессесна не работало. А когда я туда сложил скалярные типы с заданным размером, то вроде как получалось, что компилятор заранее знал размер и чем инициализировать, поэтому обходился без инициализации с рантаймом.
Но особо я там не вникал. Модуль древний уже, дофига где использовался, и прям вот по нормальному его перепроектировать не хотелось и вовсе. А учитывая, что все эти static std::string лежали в private секции, и доступа к ним этот класс не давал, то вполне устроило переделать начинку на скалярные типы, не меняя интерфейса класса. Тык что оставалось только пересобрать проект.
Может наведет на какую-нить мысль?
Может наведет на какую-нить мысль?
ksd>используется. а что рантайм? она статически линкуется. пишуть, что можно пользоваться только kernel32, остальное еще не загружено. ну, после перезагрузки винды же все нормально?
Если есть какие-нить статические переменные уровня класса или в cpp-файле, то по идее их как раз должна иницилизировать рантайм. А в момент загрузки, если рантайм еще не инициализирована, и есть какие-то обращения к таким переменным, то чего в этом случае произойдет один бог его знает. Может быть в этом дело?
Я нечто подобное видел, правда в exe-шнике. Но в нем для пущей липосакции был по максимуму убран рантайм. Дык вот после подключения какого-то левого модуля, у которого в cpp водился std::string статический на класс, exe-шник начал валиться прям на старте с Access Violation. Вылечил заменой всех объектных переменных вроде std::string на скалярные типы данных, вроде char[].
Насколько я тогда понял, компилятор просто размещал такие данные в data-секции exe-шника и заранее "знал" их как иницилизировать. И проблема исчезла. Там вроде как получалось, что этот статический std::string на своей инициализации выделял память, и что-то туда писал. Без рантайма на старте в релизе это ессесна не работало. А когда я туда сложил скалярные типы с заданным размером, то вроде как получалось, что компилятор заранее знал размер и чем инициализировать, поэтому обходился без инициализации с рантаймом.
Но особо я там не вникал. Модуль древний уже, дофига где использовался, и прям вот по нормальному его перепроектировать не хотелось и вовсе. А учитывая, что все эти static std::string лежали в private секции, и доступа к ним этот класс не давал, то вполне устроило переделать начинку на скалярные типы, не меняя интерфейса класса. Тык что оставалось только пересобрать проект.
Может наведет на какую-нить мысль?
Может наведет на какую-нить мысль?