Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: LoaderLock  (Прочитано 7475 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Malaja
Команда клуба

de
Offline Offline
Пол: Женский

« : 04-12-2009 10:29 » 

Попытаюсь сформулировать кратко:
1) есть проект на с++ (состоит из кучи lib-ов)
2) для основных классов этого проекта есть вреппер на <managed + unmanaged> с++ (как .lib).
3) для тестов была написана библиотека на с++ (как .lib).
4) для нее была написана библиотека- врепер на managed с++ (раз как dll). Она использует нашу либу 2)
5) есть тест на с# (под nunit)
6) для теста написана вспомогательная библиотека, опирающаяся на 4)  (как dll).
7) В самом тесте есть переменная типа 6):
Код:
private Managed_HelpLib m_helpLib = null;
в конструкторе я создаю объект:
Код:
myTest()
{
      m_helpLib = new Managed_HelpLib(15);
}

Во всех предыдущих версиях все было прекрасно, пока народ не создал текущую... Изменений куча, проследить за всеми невозможно.
Результат - после старта теста при попадании в вышеописанный конструктор я получила сообщение:

Код:
Managed Debugging Assistant 'LoaderLock' has detected a problem in 'D:\...\NUnit 2.4.1\bin\nunit.exe'.
Additional Information: DLL 'C:\Documents and Settings\teir\Local Settings\Temp\nunit20\ShadowCopyCache\4100_633954630511655168\Tests\assembly\dl3\7cdc7536\a98903d8_4074ca01\OMSp_mbt_managed.DLL' is attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.

После того, что я, невзирая на это, решила идти дальше, получила следующее уведомление:
Код:
Test.OMSp_managed_DistributionTest.C_SmokeTest (TestFixtureSetUp) :
System.IO.FileLoadException : Could not load file or assembly 'OMSp_mbt_managed, Version=30.3005.2.1, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
Exception from HRESULT: 0xE0434F4D
  ----> System.Runtime.InteropServices.COMException : Exception from HRESULT: 0xE0434F4D
где:
- Test.OMSp_managed_DistributionTest.C_SmokeTest (TestFixtureSetUp)  - мой тест
- OMSp_mbt_managed.DLL - это наша 4)


На всякий случай быстро сварганила примерчик-подобие своего теста, чтобы попытаться отловить ошибку конкретней, после чего эти сообщения приобрели чуть больше конкретики Ага

- первое:
Код:
LoaderLock was detected
Message: DLL 'D:\Views\....\bin\Debug\OMSp_mbt_managed.dll' is attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.

- второе:
Код:
System.IO.FileLoadException was unhandled
  Message="Could not load file or assembly 'OMSp_mbt_managed, Version=30.3005.2.1, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Exception from HRESULT: 0xE0434F4D"
  Source="ClassLibrary2_hlp"
  FileName="OMSp_mbt_managed, Version=30.3005.2.1, Culture=neutral, PublicKeyToken=null"
  FusionLog=""
  StackTrace:
       at ClassLibrary2_hlp.Class1_hlp..ctor(Int32 nTestCount)
       at ClassLibrary1.Class1..ctor() in D:\Views\adteir0.omsp.ap.adteir0_300614\s7p.omsp\oms\test\ClassLibrary1\ClassLibrary1\Class1.cs:line 19
       at ConsoleApplication1.Program.Main(String[] args) in D:\Views\adteir0.omsp.ap.adteir0_300614\s7p.omsp\oms\test\ClassLibrary1\ConsoleApplication1\Program.cs:line 15
       at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()

Начала искать решение...
1) Попыталась убирать по очереди изменения, но вскоре бросила, ибо их оказалось слишком много.
2) В инете нашла совет просто отключить данное сообщение и все будет хорошо.
Отключила (debud->ehsceptions->managed debugging assistant -> LoaderLock - убрать птичку), но мне это не помогло, ибо второе сообщение все равно появлялось с завидным постоянством, чего и следовало ожидать
3) потом нашла некое логичное объяснение и совет, выполнила:
в нашей библиотеке 2а) в "properties ->  linker -> advanced" для пункта "no entry point" выбрала "yes" и перекомпилировала.

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


Итого, насколько я все-таки что-то понимаю в колбасных обрезках, библиотека таки нездорова.
Вопросов несколько:
- сталкивался ли  кто-то с подобной ситуацией
- может кто-то знает, как это лечится
- самый простой - как проверить, здоров ли assembly нашей библиотеки
- можно ли вообще проверить (и если да, то как), какие из ее составляющих загружены, а какие нет
Записан

холоднокровней, Маня, Ви не на работе
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #1 : 04-12-2009 12:43 » 

Я не вполне понял. Вроде сказано, что dll содержит managed код, отчего тогда экземпляр создаётся через new, а не gcnew?

Откуда COMException, где-то ещё и COM есть?

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Malaja
Команда клуба

de
Offline Offline
Пол: Женский

« Ответ #2 : 04-12-2009 13:05 » 

Дим,

1) эта dll на с#, посему new
2) откуда там com - сама не пойму, нету его там, незачем просто...
3) насчет уровней - в том-то и дело, что не пойму, как их разобрать...
Теоретически надо как-то понять, какая из lib-ов, подключенных к той, о которой кричит винда, "нездоровы". Но вот как...
Записан

холоднокровней, Маня, Ви не на работе
Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #3 : 04-12-2009 13:45 » 

Ир, у тебя проект есть? Прверь все зависимости, компилируй не сразу всё, а по частям. От простейших (с наименьшей зависимостью).
Записан

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Malaja
Команда клуба

de
Offline Offline
Пол: Женский

« Ответ #4 : 04-12-2009 15:30 » 

Джон,
в том-то и загвоздка - компилируется все без предупреждений о проблемах (у нас warningslevel = 4).
А падает только при исполнении...
Записан

холоднокровней, Маня, Ви не на работе
Malaja
Команда клуба

de
Offline Offline
Пол: Женский

« Ответ #5 : 04-12-2009 16:44 » 

У меня уже маразм начался...

1) есть врепер для основных типов данных на <managed + unmanaged c++>, как dll
2) есть проект на managed c++, которому нужны определенные данные из 1).
Существует ли какая-то возможность затянуть статически dll-лину из 1) Не понял Просто я уже подумала - может есть, а я этого не знаю?  А черт его знает...

т.е. во врепере есть класс ClientSession, а в проекте я хочу делать так:

ClientSession sess;

Можно длл-лину прилинковать как Delay-Loaded DLLs, а затем где-то в самом начале сделать LoadLibrary(), но так я затяну только сами функции, а типы...
« Последнее редактирование: 04-12-2009 17:17 от Malaja » Записан

холоднокровней, Маня, Ви не на работе
Malaja
Команда клуба

de
Offline Offline
Пол: Женский

« Ответ #6 : 04-12-2009 17:24 » 

Все, лавочку можно закрыть:
я сейчас вставила интереа ради delay-линковку и получила такое вот сообщение:

1>LINK : warning LNK4199: /DELAYLOAD:core_managed.dll ignored; no imports found from core_managed.dll

Т.о. ситуевина пока неразруливаема.

Как выяснилось, эта самая core_managed.dll изначально рассчитана на то, что клиенты ее используют только как reference-dll в своем c#-коде.
Это мы пытались извратиться и привинтить к ней врепер для с++...

придется просто все переписать на c# и не мудрствовать лукаво...
Записан

холоднокровней, Маня, Ви не на работе
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #7 : 21-09-2012 20:02 » 

Дьявол.

Коллега как раз внёс масштабное изменение в dll на C++, снабдив всюду native-код сериализацией в XML (managed-код), и вот эта штука стала появляться.

Но вариант Malaja мне категорически не подходит.

Я это победю! т.е. побежу! в общем, одолею.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #8 : 21-09-2012 20:58 » 

Нет, это, оказалось, "шизофрения" от MS - этот LoaderLock в VS 2008 SP1 не дружит с загружаемыми DLL DirectX 9.

Обещано было исправить, но так и не поправили. Отключение LoaderLock даже улучшает положение дел - некоторые глюки исчезают.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines